Forgot your password?
typodupeerror
Google Security Technology

Gmail Drops Support for Connecting To Pop3 Servers With Self -Signed Certs 299

Posted by Unknown Lamer
from the security-through-redefinition dept.
DECula writes "In a move not communicated to its users beforehand, Google's Gmail servers were reconfigured to not connect to remote pop3 servers that have self-signed certificates, leaving folks with unencrypted connections, or no service when getting email from other services. Not good for the small folks. One suggestion was to allow placing the public keys on Google's side in the user configuration. That would be a heck of a lot better than just dropping users into never never land." Apparently, "valid" now means "paid someone Google approves to sign the certificate." It's not like commercial CAs have the best security track record either.
This discussion has been archived. No new comments can be posted.

Gmail Drops Support for Connecting To Pop3 Servers With Self -Signed Certs

Comments Filter:
  • by Frosty Piss (770223) * on Monday December 17, 2012 @07:30PM (#42320181)

    In a move not communicated to its users before hand

    In a move not communicated to you. I have a Google Apps account and received an email about this a few weeks ago.

    Not good for the small folks.

    A cert from BigNameInternetCompany costs next to nothing (although it might just be worth that much as well).

    My guess is that this is mostly driven by the desire to minimize SPAM email servers using the Google network to abuse their victims.

    One suggestion was to allow placing the public keys on Google's side in the user configuration. That would be a heck of a lot better than just dropping users into never never land.

    Again, a cert that is acceptable to Google is so dirt cheap as to be inconsequential to anyone running a server that needs one. So, the only reason can be that those that object are the crusty RMS types â" everything must be free. Google is more concerned with the health of their network, not random non-paying non-customerâ(TM)s not really needy needs.

    I know that sounds harsh, but Google is not a social services agency.

    • This cut at free flow of information, and this alligation that the cost is trivial in the parent poster's post, suggests that if it were such a nothing then google should offer a means to comply wihtout forcing people to go out and pay a third party.

      If it's so cheap and such a nothing, then what's the problem wiht them providing what is needed to interract with their own service?

      • Re: (Score:3, Insightful)

        by Threni (635302)

        Google can do what they want. This move improves security. Sometimes you have to force people to wake up so that they move their feet out of the fire.

        • Google can do what they want.

          Sure, Google can always do what they want, but please tell us, the noname folks, whether or not we can download our email from our Gmail account, to our own computer, using POP3 protocol?
           
          Thank you and to anyone who can provide us, the noname folks, the critically needed information !!
           

          • by ThatFunkyMunki (908716) <<thatfunkymunki> <at> <gmail.com>> on Monday December 17, 2012 @08:17PM (#42320707)
            Yes, you can. The only issue is that when you are using the gmail interface to download mail from an external POP3 server, if you want the connection to be encrypted, your SSL certificate cannot be self-signed. This does not affect anything to do with using regular gmail with a regular POP3 client.
            • Yes, actually it does. Our company was getting along nicely with a self-signed cert which we added to all the company devices as a trusted source. One enterprising engineer was using gmail. When they dropped the change on us, he could no longer use gmail and in the spirit of letting VIPs get away with anything they want mostly, we were forced to buy real certs. I'm not against real certs - especially for a company - but you can't just use plain socket access because our server broadcasts STARTTLS as an opti

          • by PhunkySchtuff (208108) <{ua.moc.acitamotua} {ta} {iak}> on Monday December 17, 2012 @08:18PM (#42320709) Homepage

            From my reading of the linked article, this has nothing whatsoever to do with fetching your email from Google over POP3 (or POP3S)

            What this affects is if you are running a mailserver that uses a self-signed certificate, or if you're using another email account on a mailserver that uses a self-signed certificate, then you can no longer tell your gmail account to pull the email in from your second account over POP3S, as it can't verify the certificate.

            You can still have gmail pull in your POP email via the non-secure protocol, or have the mail server administrator pay the $30 or so a year it costs to get a valid certificate signed by a recognissed CA.

            You can still fetch your gmail via POP, using SSL or not, although why anyone would want to use POP if they're given any other option (such as IMAP) is beyond me.

        • by vsync64 (155958)

          So why can't they move their feet out of the fire by verifying the public key themselves and uploading it into their own Gmail account?

          No registrar can beat the verification of me pasting the public key from my own server and verifying the fingerprint out-of-band.

          • by Luckyo (1726890)

            As pointed out above, the point is most likely to help deflect spam servers using gmail.

            • by dch24 (904899)
              How does this deflect spam? Unless user accounts were getting hijacked just to add a POP3 server I fail to see how this helps.
            • This doesn't help fight spam, and it's retarded from a security perspective. It doesn't help fight spam, because the user must explicitly configure the POP3 server for Google to pull mail from and they will get the spam that is on that POP3 server irrespective of the security of the connection. It is retarded from a security perspective because you have two communication endpoints that are accessible by the end user and so, rather than asking the user to validate the security credentials, they require the
        • by icebike (68054) on Monday December 17, 2012 @08:18PM (#42320711)

          This move improves security.

          How does it do that?

          This change only affects those people who configure Gmail to pop mail off of small company (or personal) Linux box which has a self signed certs so that the traffic is encrypted. It then puts this mail in your Gmail inbox. I fail to see any big security hole here. Who is going to run super secret mail on a self signed certificate?

          The work around is to have the Linux box forward a copy to Gmail. At least they would then be using Googl's cert. I'm not seeing this as that much better for over all security.

          • by Albanach (527650) on Monday December 17, 2012 @10:22PM (#42321639) Homepage

            How does it do that?

            Presumably if you trust self-signed certificates, anyone can launch a MITM attack against your server with a self-signed certificate. Google would trust the self-signed certificate as being your own and then relinquish your login credentials when it attempts to retrieve the mail.

            Now the MITM has to at least get a certificate from a trusted source that will have to, at a minimum, perform some sort of domain validation.

            The increase in security may not be huge, but there's certainly some gain in security from this, and well worth the few dollars that a domain authenticated certificate costs.

            • by Shagg (99693)

              Presumably if you trust self-signed certificates, anyone can launch a MITM attack against your server with a self-signed certificate. Google would trust the self-signed certificate as being your own and then relinquish your login credentials when it attempts to retrieve the mail.

              But why does Google care? If someone wants to run their own server that could be open to a MITM attack, that's their decision. It's not a good idea, but it's got nothing to do with Google and doesn't effect the security of Google's service at all.

        • by msauve (701917) on Monday December 17, 2012 @08:25PM (#42320775)
          "This move improves security."

          No, it doesn't. According to Google:

          you can disable using SSL in Gmail by unchecking 'Always use a secure connection (SSL) when retrieving mail on the Accounts and Import tab in your Mail settings. However, this means that your password and email will not be protected while sent over the Internet, so we don't recommend disabling this.

          so, instead of using SSL for it's encryption capabilities (Google is now forcing authentication as a bundle), some users will have to leave the connection wide open. Now, I realize that self-signed certs still leave an opportunity for MITM attacks, but something is better than nothing. Google could have cached self signed certs, and notified the user if they changed, which would have at least made MITM interception apparent. They could have made this level of SSL authentication configurable. They could allow users to upload a private CA cert, or the public side of an SS cert. But they didn't. They just changed to "all or nothing," which will push many users to "nothing."

          That in no way improves security.

          • Re: (Score:3, Insightful)

            by blueg3 (192743)

            instead of using SSL for it's encryption capabilities (Google is now forcing authentication as a bundle)

            Because an encrypted communication using only an IP address for authentication is no encryption at all. Any attacker reasonably capable of intercepting your communications to read them is also capable of undetectably executing a man-in-the-middle attack on the SSL connection.

            This increases security because it encourages people who actually want encrypted POP connections to use an approach that actually provides that rather than using an approach that appears to provide it but doesn't.

            It would be nice to hav

        • by X.25 (255792)

          Google can do what they want. This move improves security. Sometimes you have to force people to wake up so that they move their feet out of the fire.

          Haha.

          Ok, how does this improve security, pretty please?

          • by BitZtream (692029)

            People who actually understand security know that a false sense of security (i.e. any self signed cert) is a bad move and results in lower security since silly people who don't understand what they are doing think they are secure when they aren't.

            • by sjames (1099)

              And people who REALLY really understand security know that a self-signed cert validated by fingerprint out of band is much safer than a CA signed cert.

      • Re: (Score:3, Insightful)

        by spcebar (2786203)
        Agreed. The problem is not the levity of the price, but the existence of the price itself.
        • Agreed. The problem is not the levity of the price, but the existence of the price itself.

          Right, because everything should be free as in beer right? Even if it costs someone else something to provide it to you, it shouldn't cost you a thing, right?

          A lot of geeks here need to start to realize that all that stuff Out There(tm) isn't produced for free, and won't be free as in beer to you forever. Don't like what Google did? Use another solution or roll your own. *That* is freedom.

          • by spcebar (2786203)
            I don't think anyone's arguing that you should have to pay for a service that costs money to provide- I think we're just miffed that a service that worked and was free has been altered so that it can be no longer. I think anyone would be willing to pay for a service that costs money to provide (and a lot of us geeks do, i.e, linux is free but support costs money), but when it comes down to it, A. Google isn't exactly strapped for cash, and B. As IBitOBear suggested, the cost is trivial, and Google really ou
      • by PlusFiveTroll (754249) on Monday December 17, 2012 @07:44PM (#42320327) Homepage

        Will it work with STARTSSL free personal certs?

        http://www.startssl.com/?app=1 [startssl.com]

        • by morcego (260031)

          Will it work with STARTSSL free personal certs?

          http://www.startssl.com/?app=1 [startssl.com]

          If they offer a valid certificate chain, it should.

          • by ls671 (1122017) on Monday December 17, 2012 @10:23PM (#42321647) Homepage

            I use STARTTLS so Google servers can use my SMTP server with authentication to relay mail I send from gmail. The idea is that I can post from gmail using my real email address and not my gmail address. Trying to relay mail with my real address directly from gmail servers would cause problems with SPF (Sender Policy Framework). It that case, gmail puts your real address in the Reply-To field and puts your gmail address in the From field so it is obvious for people receiving my emails that I posted from gmail.

            I do not have gmail servers popping mail from any of my servers so I haven't tested it.

            After testing a few minutes ago, I can tell you although that gmail still works with my self-signed certificate when it connects to my SMTP server to relay mail. So, having gmail relay mail through your SMTP server still works with a self-signed cert. In order to enable this functionality, you have to provide gmail with a user name and password to connect to your SMTP server.

            Dec 17 21:33:38 mailserver sm-mta[13455]: STARTTLS=server, relay=mail-qc0-f171.google.com [209.85.216.171], version=TLSv1/SSLv3, verify=FAIL, cipher=RC4-SHA, bits=128/128
            Dec 17 21:33:38 mailserver sm-mta[13455]: AUTH=server, relay=mail-qc0-f171.google.com [209.85.216.171], authid=XXX@XXXX, mech=PLAIN, bits=0
            Dec 17 21:33:39 mailserver sm-mta[13455]: qBI2XaZT013455: from=XXXX@XXXX, size=2286, class=0, nrcpts=1, msgid=CAHEH8eWJ121WWK9o87V8SSttDhRHTHZa2NgiygugupZ0ROd3gQ@mail.gmail.com, proto=ESMTP, daemon=MTA, relay=mail-qc0-f171.google.com [209.85.216.171]

        • by IVI4573R (614125) on Monday December 17, 2012 @08:30PM (#42320821)
          Yes. My dovecot server is configured with a Class 1 from STARTSSL and Gmail is happy with it. You just have to remember to use the "Server Certificate Bundle with CRLs" provided by STARTSSL in the ssl_ca option so that the chain to CA is complete.
      • by hobarrera (2008506) on Monday December 17, 2012 @08:05PM (#42320595) Homepage

        You're right, they're not cheap. Actually they're free [startssl.com].

      • Re: (Score:3, Interesting)

        by PhunkySchtuff (208108)

        The paying to get a SSL certificate only affects people running a mail server, not people using a mail server.
        If you're running a mail server, you should really get a recognised SSL certificate if you want to offer SSL protected services, otherwise you're only getting half the benefit of SSL connections - you get encryption but not authentication.

        From my reading of the linked article, this has nothing whatsoever to do with fetching your email from Google over POP3 (or POP3S)

        What this affects is if you are r

        • by msauve (701917) on Monday December 17, 2012 @09:17PM (#42321195)
          "you should really get a recognised SSL certificate if you want to offer SSL protected services, otherwise you're only getting half the benefit of SSL connections - you get encryption but not authentication."

          No, it's perfectly reasonable to run your own CA, as an individual or an organization, distribute your CA cert to those using the service, and go merrily on your encrypted and authenticated way.

          Except for Google, who provides no mechanism to associate a private CA cert, or the public side of a self signed one, with a gmail account.
          • No, it's perfectly reasonable to run your own CA, as an individual or an organization, distribute your CA cert to those using the service, and go merrily on your encrypted and authenticated way.

            For $30 per year to get a real cert (or even less, a little googling will quickly product things like 80% off at GoDaddy etc), your time has to be of quite a low value if it's easier/cheaper to run your own CA and distribute certificates (unless, of course, you're doing it all for the fun of it)

            Where self-signed certs are no good is when you need to access your SSL protected service from someone else's machine, or a machine you've not used to access the service from before, and you have to take it on blind faith (or remember a long and complicated fingerprint) that the cert you're getting is the correct one.

            • by msauve (701917) on Monday December 17, 2012 @09:42PM (#42321379)
              "your time has to be of quite a low value if it's easier/cheaper to run your own CA and distribute certificates"

              Or, you're a large organization and running your own CA means saving $30 x (large number N) per year. Or, you're aware that getting a "real" cert is no guarantee of security.
              • If you're a large organisation, you still don't have a large number N of web-facing servers that need real SSL certificates. You might have a huge number of internal servers, and then absolutely you'll have your own internal CA, but for internet-facing servers that have incoming SSL connections to them, $30 for a cert on a $5-10k Exchange box is a drop in the ocean.

                Anyway, for the case of what this thread was originally about, which is Google being able to connect to your mail server over POP3 secured with

              • by blueg3 (192743)

                Or, you're a large organization and running your own CA means saving $30 x (large number N) per year. Or, you're aware that getting a "real" cert is no guarantee of security.

                Or you're a large organization that trusts yourself more than you trust any CA. Like, for example, the US military, which runs its own CA.

              • by whoever57 (658626)

                Or, you're a large organization and running your own CA means saving $30 x (large number N) per year.

                Yeah, it's not like you can buy a wildcard server certificate for only $200/year....... oh wait. You can!

        • by ls671 (1122017)

          The paying to get a SSL certificate only affects people running a mail server, not people using a mail server.
          If you're running a mail server, you should really get a recognised SSL certificate if you want to offer SSL protected services, otherwise you're only getting half the benefit of SSL connections - you get encryption but not authentication..

          That isn't true. Gmail connects to my SMTP server using authentication and I use a self signed cert. This is still working right now.

          http://slashdot.org/comments.pl?sid=3322605&cid=42321647 [slashdot.org]

          http://slashdot.org/comments.pl?sid=3322605&cid=42321739 [slashdot.org]

          • In light of the subject of this story, I'd expect that they'll stop that working sometime in the near future...

            • by ls671 (1122017)

              Then, I'll just install my own webmail interface that is going to run with, you guessed it, a self signed cert. For now, I just piggy back on Google, trading off privacy concerns for not having to maintain my own webmail interface.

              Everything already goes through my mail server and nobody uses my gmail address.

      • alligation

        Is that like an allegation that hides beneath the surface of the river, biding its time?

      • by syntax (2932)

        First they have the gaul to ask us to purchase a domain name, and now this?

    • by morcego (260031) on Monday December 17, 2012 @07:50PM (#42320407)

      My guess is that this is mostly driven by the desire to minimize SPAM email servers using the Google network to abuse their victims.

      Ok, hold on a moment. What does POP3 access over SSL has to do with spam ?

    • Re: (Score:3, Interesting)

      by js33 (1077193)

      A cert from BigNameInternetCompany costs next to nothing

      In fact it costs nothing from StartSSL [startssl.com], like several commenters have pointed out, but people forget that the commercial x.509 PKI is for convenience, not security.

      A self-signed cert is highly secure as long as you can verify through independent means that it is in fact the same cert installed on your server, and as long as the private key has not been compromised. In fact this is really the only way you can really get this level of security from even

    • by Shavano (2541114)

      Again, a cert that is acceptable to Google is so dirt cheap as to be inconsequential to anyone running a server that needs one. ... Google is more concerned with the health of their network, not random non-paying non-customers not really needy needs.

      I know that sounds harsh, but Google is not a social services agency.

      No, they aren't , but if they want people to us their services they will need to make their services suit their users' needs and wants.

      And nothing is more secure than a self-signed cert distributed out-of-channel.

      • by BitZtream (692029)

        Very true ... so all 8 people that use the gmail interface to check OTHER pop3 servers are possibly going to notice it. The 4 people who run their own mail servers and are too cheap to get a CA cert are just SOL.

        Obviously I exaggerate, but really, the number of people this effects is statistically irrelevant to Google.

    • by X.25 (255792) on Monday December 17, 2012 @10:32PM (#42321705)

      Again, a cert that is acceptable to Google is so dirt cheap as to be inconsequential to anyone running a server that needs one. So, the only reason can be that those that object are the crusty RMS types Ã" everything must be free. Google is more concerned with the health of their network, not random non-paying non-customerÃ(TM)s not really needy needs.

      Please, explain us how self-signed certs impact the health of their network.

      All ears.

  • by Rich0 (548339) on Monday December 17, 2012 @07:36PM (#42320227) Homepage

    I know this will get 400 replies about how self-signed certificates don't provide complete security.

    I'd buy that argument if Google configured their servers to only accept connections over SSL with trusted certificates, and then refused to connect at all otherwise.

    However, they're still allowing unencrypted connections as well. There isn't a single attack you can mount on an SSL connection with a self-signed certificate that you can't also mount on an unencrypted connection.

    Trusted vs untrusted SSL is a false dichotomy - it neglects the most commonly used option of not using SSL at all, which is completely insecure.

    • I know this will get 400 replies about how self-signed certificates don't provide complete security. I'd buy that argument if Google configured their servers to only accept connections over SSL with trusted certificates, and then refused to connect at all otherwise. However, they're still allowing unencrypted connections as well.

      Self-signed certs don't provide any security advantage in the Gmail use case over no SSL, and SSL takes processing power on both ends (self-signed certs can be useful in security

      • You are wrong. (Score:5, Insightful)

        by Kludge (13653) on Monday December 17, 2012 @08:30PM (#42320833)

        But its better -- for Google and users -- for Google not support self-signed certs than to support them in a way which provides illusory security, which is what Google was doing before it discontinued support for them.

        That is wrong. Here is the hierarchy.
        1. No security (OK)
        2. Encryption (Better)
        3. Encryption and Authentication (Best)
        Saying that 1 is better than 2 is wrong. After Google connects to a server just once and stores the key, all subsequent connections can be encrypted and verified that they are made to the same server. This fear of encryption without authentication is very ignorant.

        • by jamesh (87723)

          But its better -- for Google and users -- for Google not support self-signed certs than to support them in a way which provides illusory security, which is what Google was doing before it discontinued support for them.

          That is wrong. Here is the hierarchy.
          1. No security (OK)
          2. Encryption (Better)
          3. Encryption and Authentication (Best)
          Saying that 1 is better than 2 is wrong. After Google connects to a server just once and stores the key, all subsequent connections can be encrypted and verified that they are made to the same server. This fear of encryption without authentication is very ignorant.

          Disagree. Encryption doesn't matter if the encryption is to the enemy. Anyone in a position to snoop on the traffic is in a position to redirect the traffic to themselves and provide their own self-signed cert in place of yours (give me an example of where this isn't true - there might be some but there won't be many!). From a security point of view, 1 and 2 are equal, but then SSL is extra overhead and a false sense of security, so 1 is better.

          • Re:You are wrong. (Score:5, Interesting)

            by dch24 (904899) on Monday December 17, 2012 @10:17PM (#42321601) Journal
            Examples of snooping that lack the ability to do a MITM attack:

            1. Listening to an encrypted wifi session, then breaking the encryption offline

            2. Tapping into undersea fiber (the listening party is going to have a hard enough time exfiltrating the snooped bytes; setting up a "take over" command and associated equipment is prohibitive due to both the technical and political risks)

            3. Listening device inside a government facility. China famously does this for example by using a small office-supply firm to get equipment into a US facility somewhere is Asia; the copy machine has a hard drive like any copy machine and there's nothing suspicious about that, right? And then you find the second, and the third, and the fourth hard drive hidden in places you would never look. The data is exfiltrated only when the machine is replaced as part of a regular service contract.
            Need I go on?
          • by ls671 (1122017)

            Well, no. Self signed certs protect you from somebody simply sniffing the wire. Hijacking the traffic to redirect it to another host requires more effort...

            http://slashdot.org/comments.pl?sid=3322605&cid=42321807 [slashdot.org]

      • by WaffleMonster (969671) on Monday December 17, 2012 @08:33PM (#42320859)

        Self-signed certs don't provide any security advantage in the Gmail use case over no SSL

        There is an important difference in the use of SSL provides protection against passive easedropping where an attacker may only be able to listen to but not alter the contents of transmitted data.

        • Are you sure this is true? Either you intercept the initial handshake and get access to a full MITM attack, or you miss the initial handshake, and can't decode anything.

          At least, that's my understanding of how SSL attacks work.
          • by Binestar (28861) on Monday December 17, 2012 @11:25PM (#42321933) Homepage

            Sorry, but it isn't. MITM means the man in the middle pretends to be the server when you talk to him, then pretends to be you when the server talks to him. He then stands in the middle, encrypting to you, encrypting to the server, pretending to be both.

            Check out this video for the video that finally caused me to "get" it. https://www.youtube.com/watch?v=3QnD2c4Xovk [youtube.com]

            • Yes, that's exactly what I meant. Maybe I wasn't clear in my original post.

              The only way to break the encryption is to launch a man-in-the-middle attack. You need to pretend you are the other side, to both sides.

              If you are merely listening, you won't be able to get anything. However, if do you have the MITM, then you will be able to modify traffic, not just listen.

              So those are your only to options, intercept the initial handshake with a MITM attack which gives you full access, or you will have no acce
      • by ls671 (1122017)

        Untrue, you can still authenticate when using a self signed cert with username and password. The benefit of using a self signed cert is that someone sniffing the wire won't be able to read the data or steal your authentication credentials.

        http://slashdot.org/comments.pl?sid=3322605&cid=42321777 [slashdot.org]

    • by Burning1 (204959) on Monday December 17, 2012 @08:04PM (#42320577) Homepage

      This misses the point that trusting self signed certificates significantly reduces the security of CA signed certificates.

      In order to protect against Man in the Middle and other identity based attacks, Google needs a way of certifying that the remote machine is who they say they are. If the service trusts an self-signed certificate, there's nothing preventing a 3rd party from performing a MITM attack by intercepting your traffic and re-signing it with their own key. The only workaround would be to use a known_hosts based system, similar to SSH. This however increases the costs of administration, and still provides avenues of attack.

      I generally agree with Google's move. I think it's a bad thing to compromise the security of CA certs in order to support self-signed certs.

    • by X.25 (255792)

      I know this will get 400 replies about how self-signed certificates don't provide complete security.

      Self-signed certs are much more secure than 'commercial' certs.

      Anyone telling you anything different is simply lying and/or doesn't know what he's talking about.

  • by Vekseid (1528215) on Monday December 17, 2012 @07:40PM (#42320275) Homepage

    That means you have to control at least one IP address.

    It's also really hard to send e-mail without at least one domain of your own.

    Reseller pricing of low-end certificates is about the same cost as a domain. From Namecheap and elsewhere.

    That said, I didn't know about this, and forgot to set up SSL at one of my domains. I didn't much care, but my reaction to this is pretty much "Oh, so that's what Google is bitching about. Okay."

    This is much ado about rather little.

  • by Nyder (754090) on Monday December 17, 2012 @08:01PM (#42320521) Journal

    You get what you pay for.

  • Free, trusted, certificates from https://www.startssl.com/ [startssl.com] - no excuse at all for using self signed, at least until DANE/TLSA [ietf.org] is deployed.

  • Why would I have to pay?
    I could just get a free cert from StartSSL, which is trusted by most mayor OS, browsers, and mobile devices.
    It's also trusted by chrome on *nix (in windows it uses the OS certificates - which include StartSSL).

  • Gmail servers were reconfigured to not connect to remote pop3 servers that have self-signed certificates, leaving folks with unencrypted connections, or no service when getting email from other services.

    Sorry for the ignorance, but I don't understand this. Why would I be getting email from a "remote POP3 server" or "other service"? Why wouldn't I just have my email client connect directly to Gmail's POP3 server?

    pop.gmail.com port 995 using SSL. I'm using Thunderbird and it works fine.

    • Re:Please Explain (Score:4, Informative)

      by Wingman 5 (551897) on Monday December 17, 2012 @08:30PM (#42320817)
      This is if you want GMail to query another POP3 server and pull it in to GMail, this allows you to do things like use the GMail Web UI for servers that only support POP3.
    • by tizan (925212)

      It is the reverse they are talking about..
      Using gmail to check your other e-mails on other servers using POP-3 (as an individual user you are allowed 5 different of such connections)...This is not about reading your gmail mail in your favorite e-mail program.

       

  • by AaronLS (1804210) on Monday December 17, 2012 @08:34PM (#42320865)

    I like self-signed certs because they are away to leverage SSL support for encrypted connections, but they are vulnerable to man-in-the-middle attacks. Hence the suggested workaround of providing the public key in the Google account so that Google can prevent man-in-the-middle attacks. IMO that is a reasonable suggestion, but many tools for creating self signed certs don't give you an easy way to separate the public key without opening the file and being knowledgeable of it's format. It would be a feature used by probably a tiny percentage of users, and be a point of what-the-heck-is-that-option for the rest. The lack of user understanding would also be a vulnerability, where people might be duped into providing a different public key with malicious origins.

    This has nothing to do with the inflammatory "valid" vs. "paid" statement. There are CAs that provide free certificates, and thus are not vulnerable to man-in-middle-attacks because of the verifiable chain. So they are indeed valid in a sense that there is the trust chain, yet not paid, making the summary's inflammatory statement INVALID. No one is trying to claim self signed certs are invalid, they just leave users vulnerable.

    The last statement about CA's being compromised is somewhat irrelevant to the subject at hand. They seem to be trying to make the point of Google unfairly favoring CA signed certs over self signed certs. So they either feel that Google should also do away with CA signed cert support, or not do away with self signed certs on the basis that CA signed certs are no more secure(as a result of CA's being compromised). I will address both of these possibilities.

    1) Doing away with self signed certs prevents vulnerabilities that most users are probably unaware exist. Thus avoiding more shenanigans like Chinese activists getting arrested when the government snoops their communications using man-in-the-middle attacks. So this is definitely a step in the right direction(although perhaps alternatively could have supported providing public keys out of channel as summary suggests).

    2) Doing away with support for CA signed certs to close the potential vulnerability of relatively rare forged certs? That's like throwing the baby out with the bath water. The system in place significantly improves security for the vast majority of connections. It allows certs to be revoked when found to be forged, and provides a secure connection that cannot be snooped(with the exception of the tiny fraction of invalid certs, which that get revoked anyhow). Self signed certs cannot offer either of these features transparently(without requiring users to setup public keys).

    Self-signed certs can be "forged" in the sense that a man-in-the-middle can present a completely different cert. as the original, and there is no third party verification that would allow that cert to be revoked. Even if it were revoked("hey bob, just calling to tell you to look at the cert on that connection when you get your email and if the key read f0a135... then disconnect" I kid, I kid), the malicious snooper would just create a new self-signed cert for another man-in-the-middle the next time a connection is initiated. For those same reasons, connections made with self-signed certs have very little guarantee of security.

    Usually I'm not concerned about man-in-the-middle attacks, since if someone has gained that level of access to the network I'm connecting over, then things are looking bad already. In places like China though, where the people who control the network are the people who want to snoop on you, it is a ever present danger.

    If there were more user friendly systems in place for managing/retrieving public keys, then self signed certs would be great. Even when I know a cert. is valid, some make it very hard to permanently add the public key as trusted, and thus prompt me with an extra step every time I restart my browser and try to access a page using one.

    • by Skapare (16644)

      There are two ways to verify a client that is connecting with some private key. The more commonly known method involves the client providing its signed public key, and verifying the signature (a use of the signer's private key) against its known and trusted public key. Then it is assumed if the trusted signer signed this user public key, then the signer trusted the user, and so the server can trust the user as well. The less commonly known method involves the server having a copy of the user public key,

      • by AaronLS (1804210)

        SSH comes to mind quite often when thinking about these kinds of things. In most places, users see prompts about accepting a public key so often that it becomes second nature. No one goes to the IT admin and is like "Hey, did something change on the server that would cause me to see this message today, or is someone intercepting my connection and providing their own public key?". Maybe not in that wording, but the point being, even savvy users in a computer science department generally ignore these messa

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Usually I'm not concerned about man-in-the-middle attacks, since if someone has gained that level of access to the network I'm connecting over, then things are looking bad already.

      No, things aren't looking bad, things are looking normal.

      I trust my local network, and I trust the destination network, but a simple traceroute will show that my packets have to traverse 6 to 8 other networks that belong to other people to get to their destination. Do I trust the owners of those networks not to be malicious? Do I

  • The Perspectives [perspectives-project.org] notary system could be updated to include mail servers. Then everyone, including organizations like Google, could check notaries to make sure they weren't getting MITM'd.

  • For the administrator of an enterprise mail server, which offers users the ability to check mail from the outside using POP/SSL or IMAP/SSL, The whole POP/IMAP feature of Gmail is scaring. You insist that your users should not disclose their password to anyone, and some of them see no problem in giving their credentials to Google, a patriot-act constrained third party.

    What can be done here? Block GMail IP range for POP and IMAP? Request a client certificate to be presented?

  • If so then all griping here about the lack of free certificates is for naught...

  • As much as I want to like Google they really slip up sometimes.
    Regardless of whether there is a good reason for the latest change, Google has absolutely no qualms about the way it draws large numbers of people to use what is perceived as public infrastructure (it isn't, but Google search being the ubiquitous, number one engine there is a gray area in perceptions of trustworthiness), then drops it (infrastructure services) like a hot potato if the numbers don't meet their definition of "huge".
    You can't just

  • Not that many people are talking about it, but Exchange support for GMail is also going away for free customers on Jan 13. That is a huge deal.

    That means no push notification of GMails on the iPhone without using the GMail app.

    Google's strategy is becoming clearer vis-a-vis iOS: replace Apple's native apps with its own. People will be forced to use the GMail app instead of native iOS mail if they want push notifications. Same thing with Maps---people are going to use Google's maps app whenever possible. At least Apple managed to grab a foothold with iMessage. That one won't be replaced by Google soon.

The major difference between bonds and bond traders is that the bonds will eventually mature.

Working...