I'm hoping to reach out to google's gmail engineers with this message, Today I noticed that for the past 3 days, email messages from my personal website's pop3 were not being received into my gmail inbox. Naturally, I figured that my pop3 service was down, but after some checking, every thing was working OK. I then checked gmail settings, and noticed some error. It explained that google is no longer accepting self signed ssl certificates. It claims that this change will "offer[s] a higher level of security to better protect your information". I don't believe that this change offers better security. In fact it is now unsecured - I am unable to use ssl with gmail, I have had to select the plain-text pop3 option. I don't have hundreds of dollars to get my ssl certificates signed, and to top it off, gmail never notified me of an error with fetching my mail. How many of email accounts trying to grab mail are failing now? I bet thousands, as a self signed certificate is a valid way of encrypting the traffic. Please google, remove this requirement. Source: http://support.google.com/mail/bin/answer.py?hl=en&answer=21291&ctx=gmail#strictSSL
On Fri, 14 Dec 2012 09:47:03 -0600 Randy <nanog@afxr.net> wrote:
I'm hoping to reach out to google's gmail engineers with this message, Today I noticed that for the past 3 days, email messages from my personal website's pop3 were not being received into my gmail inbox. Naturally, I figured that my pop3 service was down, but after some checking, every thing was working OK. I then checked gmail settings, and noticed some error. It explained that google is no longer accepting self signed ssl certificates. It claims that this change will "offer[s] a higher level of security to better protect your information". I don't believe that this change offers better security. In fact it is now unsecured - I am unable to use ssl with gmail, I have had to select the plain-text pop3 option.
I don't have hundreds of dollars to get my ssl certificates signed, and to top it off, gmail never notified me of an error with fetching my mail. How many of email accounts trying to grab mail are failing now? I bet thousands, as a self signed certificate is a valid way of encrypting the traffic.
http://www.startssl.com/ Their certs are free and, from what I hear, are accepted by Google. -- John
Their certs are free and, from what I hear, are accepted by Google.
Seconded. I was a hold-out for a long time on personal stuff - I trust me, I'm not paying someone else to trust me - but StartSSL makes a lot of the pain go away with minimal effort. Regards, Tim.
On Fri, Dec 14, 2012 at 11:21 AM, Tim Franklin <tim@pelican.org> wrote:
Their certs are free and, from what I hear, are accepted by Google.
Seconded. I was a hold-out for a long time on personal stuff - I trust me, I'm not paying someone else to trust me - but StartSSL makes a lot of the pain go away with minimal effort.
because paying for random numbers is craziness.
On Fri, Dec 14, 2012 at 11:36:08AM -0500, Christopher Morrow wrote:
Seconded. I was a hold-out for a long time on personal stuff - I trust me, I'm not paying someone else to trust me - but StartSSL makes a lot of the pain go away with minimal effort.
because paying for random numbers is craziness.
Of course, the same logic applies to IP addresses >;>
On Fri, Dec 14, 2012 at 12:04 PM, Eugen Leitl <eugen@leitl.org> wrote:
On Fri, Dec 14, 2012 at 11:36:08AM -0500, Christopher Morrow wrote:
Seconded. I was a hold-out for a long time on personal stuff - I trust me, I'm not paying someone else to trust me - but StartSSL makes a lot of the pain go away with minimal effort.
because paying for random numbers is craziness.
Of course, the same logic applies to IP addresses >;>
see odd tunderwood's presentation on using random numbers for ip addressing, without registry support for same.
On 12/14/2012 10:47 AM, Randy wrote:
I don't have hundreds of dollars to get my ssl certificates signed
You can get single-host certificates issued for free from StartSSL, or for very cheaply (under $10) from low-cost providers like CheapSSL.com. I've never had a problem having my StartSSL certs verified by anyone. - Pete
On Fri, Dec 14, 2012 at 10:52 AM, Peter Kristolaitis <alter3d@alter3d.ca> wrote:
On 12/14/2012 10:47 AM, Randy wrote:
I don't have hundreds of dollars to get my ssl certificates signed
You can get single-host certificates issued for free from StartSSL, or for very cheaply (under $10) from low-cost providers like CheapSSL.com. I've never had a problem having my StartSSL certs verified by anyone.
This doesn't solve the problem if you have your own internal PKI or want to use a certificate that is valid for more than a year. StartSSL is a good option, but not everyone will be able to switch for a variety of reasons. Google should provide a way of uploading trusted root CAs (including self-signed certs) if they want to perform strict validation. - Max
A major problem with free or low-cost certificates is that their intermediate CA certificate does not always point back to a root certificate in client machines and/or software. matthew black california state university, long beach -----Original Message----- From: Peter Kristolaitis [mailto:alter3d@alter3d.ca] Sent: Friday, December 14, 2012 7:53 AM To: nanog@nanog.org Subject: Re: Gmail and SSL On 12/14/2012 10:47 AM, Randy wrote:
I don't have hundreds of dollars to get my ssl certificates signed
You can get single-host certificates issued for free from StartSSL, or for very cheaply (under $10) from low-cost providers like CheapSSL.com. I've never had a problem having my StartSSL certs verified by anyone. - Pete
I've heard this argument fairly often when I mention free/cheap certificates to colleagues, etc, but no one has ever actually pointed to a reasonable case where this is true ("the 20 year old VMS system that I've never patched running OpenSSL 0.0.0.0.1-pre-alpha doesn't work" doesn't count...). I tested my StartSSL certs against quite a number of clients and haven't found anything reasonably modern (say in the last 10 years) that didn't work either out of the box or by updating the root CA list from the OS vendor via the OS' standard patching mechanism In my experience, free/cheap certs "not working" on some clients is, in 99.9% of cases, a misconfiguration error where the server isn't presenting the cert chain properly (usually omitting the intermediate cert), which works on some platforms (often because they include the intermediate certs to work around these kinds of problems) but not on others. Fixing the cert chain that's presented to the client has ALWAYS resolved these types of issues in my experience. If you have specific example that you know breaks with a specific (free/cheap cert, client) pair, I'd love to know so I can test it (if possible, i.e. I can actually get my hands on the client device/software). - Pete On 12/14/2012 4:45 PM, Matthew Black wrote:
A major problem with free or low-cost certificates is that their intermediate CA certificate does not always point back to a root certificate in client machines and/or software.
matthew black california state university, long beach
-----Original Message----- From: Peter Kristolaitis [mailto:alter3d@alter3d.ca] Sent: Friday, December 14, 2012 7:53 AM To: nanog@nanog.org Subject: Re: Gmail and SSL
On 12/14/2012 10:47 AM, Randy wrote:
I don't have hundreds of dollars to get my ssl certificates signed You can get single-host certificates issued for free from StartSSL, or for very cheaply (under $10) from low-cost providers like CheapSSL.com. I've never had a problem having my StartSSL certs verified by anyone.
- Pete
On Fri, Dec 14, 2012 at 6:03 PM, Peter Kristolaitis <alter3d@alter3d.ca> wrote:
In my experience, free/cheap certs "not working" on some clients is, in 99.9% of cases, a misconfiguration error where the server isn't presenting the cert chain properly (usually omitting the intermediate cert), which works on some platforms (often because they include the intermediate certs to work around these kinds of problems) but not on others. Fixing the cert chain that's presented to the client has ALWAYS resolved these types of issues in my experience.
and in the case of the original topic... if the gmail servers don't accept StartSSL certs, please let me know I'll see about a fix.
On Fri, 14 Dec 2012, Christopher Morrow wrote:
On Fri, Dec 14, 2012 at 6:03 PM, Peter Kristolaitis <alter3d@alter3d.ca> wrote:
In my experience, free/cheap certs "not working" on some clients is, in 99.9% of cases, a misconfiguration error where the server isn't presenting the cert chain properly (usually omitting the intermediate cert), which works on some platforms (often because they include the intermediate certs to work around these kinds of problems) but not on others. Fixing the cert chain that's presented to the client has ALWAYS resolved these types of issues in my experience.
and in the case of the original topic... if the gmail servers don't accept StartSSL certs, please let me know I'll see about a fix.
Tangentially to this: any chance of supporting TLSA/DANE records for _110._tcp.domain and _995._tcp.domain? (and the IMAP equivalents). That would let people carry on using self signed certs who prefer to and let people who have a cert that chains back to a root CA assert which root CA the cert should chain back to, which would be nice in these days of diginotar and comodo hacks... -- [http://pointless.net/] [0x2ECA0975]
On 12/14/12, Randy <nanog@afxr.net> wrote: [snip]
It explained that google is no longer accepting self signed ssl certificates. It claims that this change will "offer[s] a higher level of security to better protect your information".
Hm... Self-signed certificates, or (worse) the use of hostnames not on the certificate, are very common with POP/SMTP/IMAP over SSL/TLS servers; when setting up POP software, it is common that the user of an e-mail service will have instructions to check and install the certificate in the e-mail client, instead of requiring a unique IP address for every POP server mail domain, and a user purchased SSL certificate for each IP. The "major CAs" are not an authoritative list of CAs that may be used to sign POP, IMAP, or SMTP server certificates for various POP servers' on the internet; so Google's choices would seem poorly conceived in that regard. If Google should wish to enforce a validation of SSL certificates, the PKI authority required, should be specified by the user, not Google, or there should be a provision to accept any certificate whatsoever, by fingerprint, for a specific hostname; defined by the user. Google should go back to definitions. What is security: security is the assurance that the Confidentiality, Integrity, and Availability of data and systems are protected. How does this change apparently impact the assurances against risk? Availability: This change breaks availability, for users accessing servers already using self-signed certificates. (In other words, the change itself is a compromise of security; the risk that you lose availability of access to your mail that you expect to be downloaded via POP3 is 100%, if you have a self-signed cert in place) Confidentiality: The change prevents any transfer of data at all, unless the user of a self-signed certificate makes one of three changes: (1) Stop using gmail POP download altogether, in this case, confidentiality assurance may be improved, because no email can be downloaded and used with the service. In general, this may not be much of an improvement, when email has already been transmitted in cleartext, before it was placed on the remote POP server. (That might be their intended result -- discourage use of POP downloads) (2) Stop using SSL, and use regular POP3 instead. In this case, confidentiality will be no better than before, and may be significantly worse. A new risk of breach by 'passive sniffing' is created. When using SSL with a self-signed certificate; passive sniffing, or Deep packet inspection was not a risk: an active attack was a requirement. Therefore, being forced to "never use SSL", even without a CA signed cert, is not an improvement, and a potential increase in risk. (3) Users may buy an official certificate, from a 3rd party CA that Google trusts. In this case, the SSL encrypted POP3 connections from Google to the POP server, will have strong protection against possible exposure of data in transit due to active Man-in-the-middle attack. * In other words: If you deem Man-in-the-Middle attack more likely than Passive sniffing exposure attacks to discover users' passwords, and the majority of users' POP servers likely to have or get certificates from a CA that Google trusts, then forced rejection of any other certificates may be an improvement in assurance against these risks; forcing the remaining users to not use SSL, and risk their password being exposed is OK, because you deemed MITM the greater risk. If you do not make that assumption, then it is not clear at all, whether assurance of confidentiality has been improved or not; it may be improved slightly for some users, and terribly harmed for many others. Integrity: The change prevents any transfer of data at all, unless the user of a self-signed certificate makes one of three changes: (1) Stop using POP download altogether, in this case, data cannot be altered by an unauthorized user as it transits the network, data that wasn't downloaded couldn't have been tampered with. (2) Stop using SSL, and use regular POP3 instead. In this case, a new risk of "transparent inline tampering" is created, without encryption, a full blown MITM attack is not required, a passive interceptor can flip random bits, as long as they update the corresponding IP checksums; so there are new significant risks to integrity. (3) Users may buy an official certificate; in this case, the risk of interception by inline Man-in-the-middle attack is reduced.
I don't believe that this change offers better security. In fact it is now unsecured - I am unable to use ssl with gmail, I have had to select the plain-text pop3 option.
I don't have hundreds of dollars to get my ssl certificates signed, and to top it off, gmail never notified me of an error with fetching my
-- -JH
participants (10)
-
Christopher Morrow -
Eugen Leitl -
Jasper Wallace -
Jimmy Hess -
John Peach -
Matthew Black -
Maxim Khitrov -
Peter Kristolaitis -
Randy -
Tim Franklin