Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
On 30/05/14 18:53, Joshua Cranmer wrote: Forgive me, but that sounds like I'm going to propose a solution with one glaring flaw that has always sunk it in the past, and then gloss over that flaw by saying 'I don't have the security experience - someone else fix it'. Actually, that is essentially what I'm saying. I know other people at Mozilla have good security backgrounds and can discuss the issue, and I was hoping that they could weigh in with suggestions on this thread. I acknowledge that the re-keying is a difficult issue, but I also don't have the time to do the research myself on this topic, since I'm way backed up on a myriad of other obligations. https://www.youtube.com/watch?v=BKorP55Aqvgfeature=youtu.be :-) The EFF does things that aren't public?! :) It would appear so. There are many reasons why this might be - privacy, lack of time to publish, etc. I haven't asked them. More seriously, are they actively attempting to detect potential MITMs, and would they announce if they did detect one? I don't know, and presumably yes :-) Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
On (2014年05月29日 23:01), Mike Hoye wrote: On 2014-05-28, 9:07 PM, Joshua Cranmer wrote: Two more possible rationales: 1. The administrator is unwilling to pay for an SSL certificate and unaware of low-cost or free SSL certificate providers. 2. The administrator has philosophical beliefs about CAs, or the CA trust model in general, and is unwilling to participate in it. Neglecting the fact that encouraging click-through behavior of users can only weaken the trust model. 3. The administrator doesn't actually believe SSL certs protect you from any real harm, and is generating a cert using the least effort possible to make a user-facing dialog box go away. It's become clear in the last few months that the overwhelmingly most frequent users of MITM attacks are state actors with privileged network positions either obtaining or coercing keys from CAs, using attacks that the CA model effectively endorses, using tech you can buy off the shelf. In that light, it's not super-obvious what SSL certs protect you from apart from some jackass sniffing the coffeeshop wifi. - mhoye I am using self-signed certificate with full knowledge of pros and cons on a server of my own. (BTW, I have found it odd to call self-signed certificate an INVALID certificate. It is a certificate OUT OF widely known CA hierarchies, but not INVALID IMHO. Invalid connotates something like a reversed from and to dates, already expired valid period, revocation URL is empty, etc., but I digress.) I would like to add another possibility: 4. A clueless user/administrator: The manual of a useful tool suggests that a self-signed certificate is used (or does not mention explicitly to use non-self-signed certification in a clear manner.) Case in point: ownCloud 5 ownCloud is a very useful open-source version of do it yourself Dropbox replacement (well almost). You can configure your own server to act like a Dropbox look-alike. I have been using it for a few months and it is very useful (basically there is no space limit, and free as in free lunch aside from the fee for network connection, PC maintenance, and electric power.) Now, ownCloud server runs as a PHP script that is invoked by web server: in my case, apache. For https: access, it needs SSL certificate, and in my case, I chose the default installation which leads to the use of default certificate (self-signed certificate.) I mentioned the possibility 4 above, because ownCloud version 5 manual never mentioned the demerit or anything of self-signed certificate. It makes sense. If a user stores his/her data in a server operated by an operator of an ownCloud service, then trusting that certificate (self-signed) from the operator is no brainer. Surely the first time you access the server, you are warned by the browser (and ownCloud sync client), but after checking finger printing, etc., you can accept it and everything should be OK. [Now, if the self-signed certificate is signed with a key that is leaked to government snoops is another story, but again it is up to the user to decide how much trusts the operator of ownCloud has. He/she may layer the local encryption before the file is stored on a remote server.] Again, if SSL is used only for end-to-end encryption among (ALREADY) trusting parties that do not share a common key in advance, self-certified cert for SSL is OK. When I checked how to use SSL certificate for Apache under Debian, documents from Debian GNU/Linux are rather scant on the philosophical issues of self-certs. The following is what I checked early during setup of ownCloud server. --- quote from my local copy of /usr/share/doc/ssl-cert/README This is a quicky package to enable unattended installs of software that need to create ssl certificates. Basically, it's just a wrapper for openssl req that feeds it the correct user variables to create self-signed certificates. --- end quote Debian Wiki: https://wiki.debian.org/Self-Signed_Certificate does not mention any demerit at this level. It explains the proper openssl command line to produce a self-signed cert. (Maybe the pages in the higher level may discuss the pros and cons of self-certs vs certs signed by widely known CA. But google search finds the above on the first page.) So I suppose someone, who was interested in ownCloud and uses Debian GNU/Linux, never had bothered to setup Apache for services that would require https:, and unfamiliar with cryptography may opt to use the defaults suggested by these packages and documentation, and ends up with self-cert by following the commands and instructions. To clear the name of ownCloud developer community, I hasten to add that ownCloud version 6 (six) manual (released in the last month or so) clearly mentioned the demerit of self-signed cert and a way to obtain a free ssl certificate. --- begin quote Apache Configuration Enabling SSL An Apache installed under Ubuntu comes already set-up with a simple self-signed certificate. All you
Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
On 29/05/14 07:01, Mike Hoye wrote: It's become clear in the last few months that the overwhelmingly most frequent users of MITM attacks are state actors with privileged network positions either obtaining or coercing keys from CAs, I don't think that's clear at all. Citation needed. I think it's more likely that they are intercepting SSL using crypto or implementation vulnerabilities without explicit CA cooperation. using attacks that the CA model effectively endorses, using tech you can buy off the shelf. In that light, it's not super-obvious what SSL certs protect you from apart from some jackass sniffing the coffeeshop wifi. Even if you are right, the answer is still everyone apart from the US government. Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
On 28/05/14 17:49, Joshua Cranmer wrote: * Insufficiently secure certificate (e.g., certificates that violate CA/Browser Forum rules or the like. I don't know if we actually consider this a failure right now, but it's a reasonable distinct failure class IMHO) We would refuse e.g. a cert with an MD5 signature. In the future, we hope to refuse certs of insufficient bitlength. It seems to me that some of these are more tolerable than others. There is a much different risk profile to accepting a certificate that expired two days ago versus one that fails an OCSP validation check. Actually, no. Because as soon as a certificate expires, the CA has no obligation to keep revocation information available for that cert. So the two are actually equivalent. That is to say, if a cert is expired, then you may not receive an OCSP response for it. And you can't make any assumptions about what that response might have been - it might have been revoked. We have an excellent chance to try to rethink CA infrastructure in this process beyond the notion of a trusted third-party CA system (which is already more or less broken, but that's beside the point). My own views on this matter is that the most effective notion of trust is some sort of key pinning: using a different key is a better indicator of an attack than having a valid certificate; under this model the CA system is largely information about how to trust a key you've never seen before. There is a minor gloss point here in that there are legitimate reasons to need to re-key servers (e.g., Heartbleed or the Debian OpenSSL entropy issue), and I don't personally have the security experience to be able to suggest a solution here. Forgive me, but that sounds like I'm going to propose a solution with one glaring flaw that has always sunk it in the past, and then gloss over that flaw by saying 'I don't have the security experience - someone else fix it'. Doesn't the EFF's SSL Observatory already track the SSL certificates to indicate potential MITMs? The SSL Observatory's available data is a one-off dump from several years ago. They are collecting more data as they go along, but it's not public. 1. Any solution should try to only permit the easy certificate override on account configuration. This minimizes scope for potential MITM attacks. That sounds like a reasonable idea, actually; by analogy with Bluetooth pairing. Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
On 5/30/2014 12:00 PM, Gervase Markham wrote: On 28/05/14 17:49, Joshua Cranmer wrote: We have an excellent chance to try to rethink CA infrastructure in this process beyond the notion of a trusted third-party CA system (which is already more or less broken, but that's beside the point). My own views on this matter is that the most effective notion of trust is some sort of key pinning: using a different key is a better indicator of an attack than having a valid certificate; under this model the CA system is largely information about how to trust a key you've never seen before. There is a minor gloss point here in that there are legitimate reasons to need to re-key servers (e.g., Heartbleed or the Debian OpenSSL entropy issue), and I don't personally have the security experience to be able to suggest a solution here. Forgive me, but that sounds like I'm going to propose a solution with one glaring flaw that has always sunk it in the past, and then gloss over that flaw by saying 'I don't have the security experience - someone else fix it'. Actually, that is essentially what I'm saying. I know other people at Mozilla have good security backgrounds and can discuss the issue, and I was hoping that they could weigh in with suggestions on this thread. I acknowledge that the re-keying is a difficult issue, but I also don't have the time to do the research myself on this topic, since I'm way backed up on a myriad of other obligations. Doesn't the EFF's SSL Observatory already track the SSL certificates to indicate potential MITMs? The SSL Observatory's available data is a one-off dump from several years ago. They are collecting more data as they go along, but it's not public. The EFF does things that aren't public?! :) More seriously, are they actively attempting to detect potential MITMs, and would they announce if they did detect one? Andrew had in his proposal a note that reporting of fingerprints could be used to detect MITMs, and I was implying that this was duplicating work others were already doing. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
On 2014-05-28, 9:07 PM, Joshua Cranmer wrote: Two more possible rationales: 1. The administrator is unwilling to pay for an SSL certificate and unaware of low-cost or free SSL certificate providers. 2. The administrator has philosophical beliefs about CAs, or the CA trust model in general, and is unwilling to participate in it. Neglecting the fact that encouraging click-through behavior of users can only weaken the trust model. 3. The administrator doesn't actually believe SSL certs protect you from any real harm, and is generating a cert using the least effort possible to make a user-facing dialog box go away. It's become clear in the last few months that the overwhelmingly most frequent users of MITM attacks are state actors with privileged network positions either obtaining or coercing keys from CAs, using attacks that the CA model effectively endorses, using tech you can buy off the shelf. In that light, it's not super-obvious what SSL certs protect you from apart from some jackass sniffing the coffeeshop wifi. - mhoye ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
On Thursday, May 29, 2014 1:30:20 AM UTC+3, somb...@gmail.com wrote: We do want all users to be able to access their email, but not by compromising the security of all users. ... This decision was made based on a risk profile of ... So it looks like we know well enough what the best approach should be in general. ... With deeply regrettable irony, a manufacturer of Firefox OS devices and one of the companies that certifies Firefox OS devices both run mail servers with invalid certificates and are our existing examples of the problem. In bug https://bugzil.la/874346 the requirement that is coming from partners is that: - we need to imminently address the certificate exception problem - the user needs to be able to add the exception from the account setup flow. (As opposed to requiring the user to manually go to the settings app and add an exception. At least I think that's the request.) I'd interpret it as follows: The partners which we cherish say that the current behavior is beyond a red line of theirs. They'd prefer if it never showed any warning, but they're willing to live with it if the warning is part of the flow. So combining those two, it looks like the highest priority is satisfying the partners, and second priority is to maybe improve the general flow of adding exceptions. I think it would help to focus on one issue, and for now it seems like that's the partner's issue. As for solutions, while contacting a trusted server every time there's an exception is an option, it does make the process more complex. What if there was a trusted server which the app contacted periodically (where the first time happens on first run etc), and download from it a list of : 1. Certificates to trust. 2. Certificates to revoke. It might be overall simpler to design and implement because it separates the the exception management (periodically with a trusted server) from the sensitive flow when users need to approve of exceptions. - avih ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
Seems like we will have to implement some sort allow invalid certs (it makes
me really sad that the system administrators and/or managers of tcl and
telefonica seem
slow to understand the risks of allowing MITM for user credentials).
I like Brian Smith's proposal to add some visual indicator when using
a non-secure connection and I also agree that making users type the
fingerprint (on a mobile device) is also a non-solution.
I propose making the user type something like:
'I understand that my password to use $mailprovider cannot be protected by
firefoxOS'
And then allow the 'one click' override. (ditto for non SSL connections).
Also in all these variations we have not discussed what should happen
if the untrusted cert changes, my guess is that we should show some delta
of the two certs (once we have detected we are not behind a captive portal)
Camilo
On 5/28/14, 4:16 PM, David Keeler wrote:
Regarding the current certificate exception mechanism:
* there is only a single certificate store on the device and therefore
that all exceptions are device-wide
This is an implementation detail - it would not be difficult to change
exceptions to per-principal-per-app rather than just per-principal.
* only one exception can exist per domain at a time
In combination with point 3, is this a limitation? Do we want to support
this? If so, again, it wouldn't be that hard.
* the exception is per-domain, not per-port, so if we add an exception
for port 993 (imaps), that would also impact https.
I don't think this is the case. Either way, it shouldn't be the case.
In summary, it would not be difficult to ensure that the certificate
exception service operates on a per-principal-per-app basis, which would
allow for what we want, I believe (e.g. exceptions for
{email-app}/example.com:993 would not affect {browser-app}/example.com:443).
In terms of solving the issue at hand, we have a great opportunity to
not implement the press this button to MITM yourself paradigm that
desktop browsers currently use. The much safer option is to ask the user
for the expected certificate fingerprint. If it matches the certificate
the server provided, then the exception can safely be added. The user
will have to obtain that fingerprint out-of-band over a hopefully secure
channel.
I would be wary of implementing a more involved scheme that involves
remote services.
Cheers,
David
On 05/28/2014 03:30 PM, Andrew Sutherland wrote:
tl;dr: We need to figure out how to safely allow for invalid
certificates to be used in the Firefox OS Gaia email app. We do want
all users to be able to access their email, but not by compromising the
security of all users. Read on if you work in the security field / care
about certificates / invalid certificates.
== Invalid Certificates in Email Context
Some mail servers out there use self-signed or otherwise invalid SSL
certificates. Since dreamhost replaced their custom CA with valid
certificates
(http://www.dreamhoststatus.com/2013/05/09/secure-certificate-changes-coming-for-imap-and-pop-on-homiemail-sub4-and-homiemail-sub5-email-clusters-on-may-14th/)
and StartCom started offering free SSL certificates
(https://www.startssl.com/?app=1), the incidence of invalid certificates
has decreased. However, there are still servers out there with invalid
certificates. With deeply regrettable irony, a manufacturer of Firefox
OS devices and one of the companies that certifies Firefox OS devices
both run mail servers with invalid certificates and are our existing
examples of the problem.
The Firefox OS email app requires encrypted connections to servers.
Unencrypted connections are only legal in our unit tests or to
localhost. This decision was made based on a risk profile of devices
where we assume untrusted/less than 100% secure wi-fi is very probable
and the cellular data infrastructure is only slightly more secure
because there's a higher barrier to entry to setting up a fake cell
tower for active attacks.
In general, other email apps allow both unencrypted connections and
adding certificate exceptions with a friendly/dangerous flow. I can
speak to Thunderbird as an example. Historically, Thunderbird and its
predecessors allowed certificate exceptions. Going into Thunderbird
3.0, Firefox overhauled its exception mechanism and for a short time
Thunderbird's process required significantly greater user intent to add
an exception. (Preferences, Advanced, Certificates, View Certificates,
Servers, Add Exception.) At this time DreamHost had invalid
certificates, free certificates were not available, invalid certificates
were fairly common, Thunderbird's autoconfig security model already
assumed a reliable network connection, Thunderbird could only run on
desktops/laptops which were more likely to have a secure network, etc.
We relented and Thunderbird ended up where it is now. Thunderbird
immediately displays the Add Security Exception UI; the user only
needs to click Confirm Security Exception.
Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
On 05/28/2014 09:30 PM, Brian Smith wrote: On Wed, May 28, 2014 at 5:13 PM, Andrew Sutherland I agree this is a safe approach and the trusted server is a significant complication in this whole endeavor. But I can think of no other way to break the symmetry of am I being attacked or do I just use a poorly configured mail server? It would be pretty simple to build a list of mail servers that are known to be using valid TLS certificates. You can build that list through port scanning, in conjunction with the auto-config data you already have. That list could be preloaded into the mail app and/or dynamically retrieved/updated. Even if we seeded this list with only the most common email providers, we'd still be protecting a lot more users than by doing nothing, since email hosting is heavily consolidated and seems to be becoming more consolidated over time. This is a good proposal, thank you. To restate my understanding, I think the key points of this versus the proposal I've made here or the variant in the https://bugzil.la/874346#c11 ISPDB proposal are: * If we don't know the domain should have a valid certificate, let it have an invalid certificate. * Preload more of the ISPDB on the device or maybe just an efficient mechanism for indicating a domain requires a valid certificate. * Do not provide strong (any?) guarantees about the ISPDB being able to indicate the current invalid certificate the server is expected to use. It's not clear what decision you'd advocate in the event we are unable to make a connection to the ISPDB server. The attacker does end up in an interesting situation where if we tighten up the autoconfig mechanism and do not implement subdomain guessing (https://bugzil.la/823640), an attacker denying access to the ISPDB ends up forcing the user to perform manual account setup. I'm interested in your thoughts here. Implementation-wise I understand your suggestion to be leaning more towards a static implementation, although dynamic mechanisms are possible. The ISPDB currently intentionally uses static files checked into svn for implementation simplicity/security, a decision I agree with. The exception is our MX lookup mechanism at https://mx.thunderbird.net/dns/mx/mozilla.com I should note that the current policy for the ISPDB has effectively been try and get people to host their own autoconfig entries with an advocacy angle which includes rejecting submissions. What's you've suggested here (and I on comment 11) implies a substantiative change to that. This seems reasonable to me and when I raised the question about whether such changes would be acceptable to Thunderbird last year, people generally seemed to either not care or be on board: https://mail.mozilla.org/pipermail/tb-planning/2013-August/002884.html https://mail.mozilla.org/pipermail/tb-planning/2013-September/002887.html https://mail.mozilla.org/pipermail/tb-planning/2013-September/002891.html I should also note that I think the automation to populate the ISPDB is still likely to require sizable engineering effort but is likely to have positive externalities in terms of drastically increasing our autoconfig coverage and allowing us to reduce the duration of the autoconfig probing process. For example, we could establish direct mappings for all dreamhost mail clusters. Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
On Thu, May 29, 2014 at 2:03 PM, Andrew Sutherland asutherl...@asutherland.org wrote: This is a good proposal, thank you. To restate my understanding, I think the key points of this versus the proposal I've made here or the variant in the https://bugzil.la/874346#c11 ISPDB proposal are: * If we don't know the domain should have a valid certificate, let it have an invalid certificate. Right. But, I would make the decision of whether to allow an invalid certificate only at configuration time, instead of every time you connect to the server like Thunderbird does. Though you'd have to solve the problem of dealing with a server that changed from one untrusted certificate to another. * Preload more of the ISPDB on the device or maybe just an efficient mechanism for indicating a domain requires a valid certificate. Right. * Do not provide strong (any?) guarantees about the ISPDB being able to indicate the current invalid certificate the server is expected to use. Right. It would be better for us to spend more effort improving security for secure servers that are trying to do something reasonable, instead of spending time papering over fundamental security problems with the server. It's not clear what decision you'd advocate in the event we are unable to make a connection to the ISPDB server. The attacker does end up in an interesting situation where if we tighten up the autoconfig mechanism and do not implement subdomain guessing (https://bugzil.la/823640), an attacker denying access to the ISPDB ends up forcing the user to perform manual account setup. I'm interested in your thoughts here. I think guessing is a bad idea in almost any/every situation because it is easy to guess wrong (and/or get tricked) and really screw up the user's config. Maybe it would be better to crowdsource configuration information much like location services do: get a few users to opt-in to reporting/verifying/voting on a mapping of MX records to server settings so that you can build a big centralized database of configuration data for (basically) every mail server in existence. Then, when users get auto-configured with that crowdsourced data, have them report back on whether the automatic configuration worked. Until we could do that, it seems reasonable to just make sure that ISPDB has the configuration data for the most common commodity email providers in the target markets for FirefoxOS, since FirefoxOS is primarily a consumer-oriented product. Implementation-wise I understand your suggestion to be leaning more towards a static implementation, although dynamic mechanisms are possible. The ISPDB currently intentionally uses static files checked into svn for implementation simplicity/security, a decision I agree with. The exception is our MX lookup mechanism at https://mx.thunderbird.net/dns/mx/mozilla.com I should note that the current policy for the ISPDB has effectively been try and get people to host their own autoconfig entries with an advocacy angle which includes rejecting submissions. What's you've suggested here (and I on comment 11) implies a substantiative change to that. This seems reasonable to me and when I raised the question about whether such changes would be acceptable to Thunderbird last year, people generally seemed to either not care or be on board: It seems like you would be able to answer this as part of the scan of the internet, by trying to retrieve the self-hosted autoconfig file if it is available. I suspect you will find that almost nobody is self-hosting it. I should also note that I think the automation to populate the ISPDB is still likely to require sizable engineering effort but is likely to have positive externalities in terms of drastically increasing our autoconfig coverage and allowing us to reduce the duration of the autoconfig probing process. For example, we could establish direct mappings for all dreamhost mail clusters. Autopopulating all the autoconfig information is a lot of work, I'm sure. But, it should be possible to create good heuristics for deciding whether to accept certs issued by untrusted issuers in an email app. For example, if you don't have the (full) autoconfig data for an MX server, you could try creating an SMTP connection to the server(s) indicated in the MX records and then use STARTTLS to switch to TLS. If you successfully validate the certificate from that SMTP server, then assume that the IMAP/POP/LDAP/etc. servers use valid certificates too, even if you don't know what those servers are. Again, I think if you made sure that GMail, Outlook.com, Yahoo Mail, 163.com, Fastmail, TuffMail, and the major analogs in the B2G markets were all marked TLS-only-with-valid-certificate then I think a huge percentage of users would be fully protected from whatever badness allowing cert error overrides would cause. Or, perhaps you could just create a whitelist of servers that are allowed to have cert error
Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
On 05/29/2014 07:12 PM, Brian Smith wrote: On Thu, May 29, 2014 at 2:03 PM, Andrew Sutherland asutherl...@asutherland.org wrote: It seems like you would be able to answer this as part of the scan of the internet, by trying to retrieve the self-hosted autoconfig file if it is available. I suspect you will find that almost nobody is self-hosting it. I agree with your premise that the number of people self-hosting autoconfig entries is so low as to not be a concern other than not breaking them and allowing that to be an override mechanism for the ISPDB. Also, https://scans.io/ has a number of useful internet scans we can use already, so I don't think we need to do the scan ourselves for our first round. While the port 993/995 scans at https://scans.io/study/sonar.cio are somewhat out-of-date (2013-03-30), the DNS dumps and port 443 scans are modern and should be sufficient to achieve a fairly comprehensive database. Especially if we make the simplifying assumption that all relevant mail servers have been operational at the same domain name since at least then. (Obviously the IP addresses may have changed so we'll need to use a reverse DNS dump from the appropriate time period.) Autopopulating all the autoconfig information is a lot of work, I'm sure. But, it should be possible to create good heuristics for deciding whether to accept certs issued by untrusted issuers in an email app. For example, if you don't have the (full) autoconfig data for an MX server, you could try creating an SMTP connection to the server(s) indicated in the MX records and then use STARTTLS to switch to TLS. If you successfully validate the certificate from that SMTP server, then assume that the IMAP/POP/LDAP/etc. servers use valid certificates too, even if you don't know what those servers are. Very interesting idea on this! Thanks! Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
On 05/28/2014 06:30 PM, Andrew Sutherland wrote: == Proposed solution for exceptions / allowing connections There are a variety of options here, but I think one stands above the others. I propose that we make TCPSocket and XHR with mozSystem take a dictionary that characterizes one or more certificates that should be accepted as valid regardless of CA validation state. Ideally we could allow pinning via this mechanism (by forbidding all certificates but those listed), but that is not essential for this use-case. Just a nice side-effect that could help provide tighter security guarantees for those who want it. Note: I've sent an email to the W3C sysapps list (the group standardizing http://www.w3.org/2012/sysapps/tcp-udp-sockets/) about this. It can be found in the archive at http://lists.w3.org/Archives/Public/public-sysapps/2014May/0033.html Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
B2G, email, and SSL/TLS certificate exceptions for invalid certificates
tl;dr: We need to figure out how to safely allow for invalid certificates to be used in the Firefox OS Gaia email app. We do want all users to be able to access their email, but not by compromising the security of all users. Read on if you work in the security field / care about certificates / invalid certificates. == Invalid Certificates in Email Context Some mail servers out there use self-signed or otherwise invalid SSL certificates. Since dreamhost replaced their custom CA with valid certificates (http://www.dreamhoststatus.com/2013/05/09/secure-certificate-changes-coming-for-imap-and-pop-on-homiemail-sub4-and-homiemail-sub5-email-clusters-on-may-14th/) and StartCom started offering free SSL certificates (https://www.startssl.com/?app=1), the incidence of invalid certificates has decreased. However, there are still servers out there with invalid certificates. With deeply regrettable irony, a manufacturer of Firefox OS devices and one of the companies that certifies Firefox OS devices both run mail servers with invalid certificates and are our existing examples of the problem. The Firefox OS email app requires encrypted connections to servers. Unencrypted connections are only legal in our unit tests or to localhost. This decision was made based on a risk profile of devices where we assume untrusted/less than 100% secure wi-fi is very probable and the cellular data infrastructure is only slightly more secure because there's a higher barrier to entry to setting up a fake cell tower for active attacks. In general, other email apps allow both unencrypted connections and adding certificate exceptions with a friendly/dangerous flow. I can speak to Thunderbird as an example. Historically, Thunderbird and its predecessors allowed certificate exceptions. Going into Thunderbird 3.0, Firefox overhauled its exception mechanism and for a short time Thunderbird's process required significantly greater user intent to add an exception. (Preferences, Advanced, Certificates, View Certificates, Servers, Add Exception.) At this time DreamHost had invalid certificates, free certificates were not available, invalid certificates were fairly common, Thunderbird's autoconfig security model already assumed a reliable network connection, Thunderbird could only run on desktops/laptops which were more likely to have a secure network, etc. We relented and Thunderbird ended up where it is now. Thunderbird immediately displays the Add Security Exception UI; the user only needs to click Confirm Security Exception. (Noting that Thunderbird's autoconfig process is significantly more multi-step.) == Certificate Exception Mechanisms in Platform / Firefox OS Currently, the only UI affordance to add certificate exceptions is exposed by the browser app/subystem for HTTPS sites. I assert that this is a different risk profile and we wouldn't want to follow it blindly and don't actually want to follow it at all[1]. There are general bugs filed on being able to import a new CA or certificate at https://bugzil.la/769183 and https://bugzil.la/867899. Users with adb push access also have the potentially to manually import certificates from the command line, see https://groups.google.com/forum/#!msg/mozilla.dev.b2g/B57slgVO3TU/G5TA-PiFI_EJ It is my understanding that: * there is only a single certificate store on the device and therefore that all exceptions are device-wide * only one exception can exist per domain at a time * the exception is per-domain, not per-port, so if we add an exception for port 993 (imaps), that would also impact https. And it follows from the above points that exceptions added by the email app/on the behalf of the email app affect and therefore constitute a risk to all other apps on the device. This is significant because creating an email account may result in us wanting to talk to a different domain than the user's email address because of the autoconfiguration process and vanity domains, etc. == The email app situation In bug https://bugzil.la/874346 the requirement that is coming from partners is that: - we need to imminently address the certificate exception problem - the user needs to be able to add the exception from the account setup flow. (As opposed to requiring the user to manually go to the settings app and add an exception. At least I think that's the request.) Taking this as a given, our goal then becomes to allow users to connect to servers using invalid certificates without compromising the security of the users who do use servers with valid certificates or of other apps on the phone. There are two main problems that we need solutions to address: 1) Helping the user make an informed and safe decision about whether to add an exception and what exception to add. I strongly assert that in order to do this we need to be able to tell the user with some confidence whether we believe the server actually has an
Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
Regarding the current certificate exception mechanism:
* there is only a single certificate store on the device and therefore
that all exceptions are device-wide
This is an implementation detail - it would not be difficult to change
exceptions to per-principal-per-app rather than just per-principal.
* only one exception can exist per domain at a time
In combination with point 3, is this a limitation? Do we want to support
this? If so, again, it wouldn't be that hard.
* the exception is per-domain, not per-port, so if we add an exception
for port 993 (imaps), that would also impact https.
I don't think this is the case. Either way, it shouldn't be the case.
In summary, it would not be difficult to ensure that the certificate
exception service operates on a per-principal-per-app basis, which would
allow for what we want, I believe (e.g. exceptions for
{email-app}/example.com:993 would not affect {browser-app}/example.com:443).
In terms of solving the issue at hand, we have a great opportunity to
not implement the press this button to MITM yourself paradigm that
desktop browsers currently use. The much safer option is to ask the user
for the expected certificate fingerprint. If it matches the certificate
the server provided, then the exception can safely be added. The user
will have to obtain that fingerprint out-of-band over a hopefully secure
channel.
I would be wary of implementing a more involved scheme that involves
remote services.
Cheers,
David
On 05/28/2014 03:30 PM, Andrew Sutherland wrote:
tl;dr: We need to figure out how to safely allow for invalid
certificates to be used in the Firefox OS Gaia email app. We do want
all users to be able to access their email, but not by compromising the
security of all users. Read on if you work in the security field / care
about certificates / invalid certificates.
== Invalid Certificates in Email Context
Some mail servers out there use self-signed or otherwise invalid SSL
certificates. Since dreamhost replaced their custom CA with valid
certificates
(http://www.dreamhoststatus.com/2013/05/09/secure-certificate-changes-coming-for-imap-and-pop-on-homiemail-sub4-and-homiemail-sub5-email-clusters-on-may-14th/)
and StartCom started offering free SSL certificates
(https://www.startssl.com/?app=1), the incidence of invalid certificates
has decreased. However, there are still servers out there with invalid
certificates. With deeply regrettable irony, a manufacturer of Firefox
OS devices and one of the companies that certifies Firefox OS devices
both run mail servers with invalid certificates and are our existing
examples of the problem.
The Firefox OS email app requires encrypted connections to servers.
Unencrypted connections are only legal in our unit tests or to
localhost. This decision was made based on a risk profile of devices
where we assume untrusted/less than 100% secure wi-fi is very probable
and the cellular data infrastructure is only slightly more secure
because there's a higher barrier to entry to setting up a fake cell
tower for active attacks.
In general, other email apps allow both unencrypted connections and
adding certificate exceptions with a friendly/dangerous flow. I can
speak to Thunderbird as an example. Historically, Thunderbird and its
predecessors allowed certificate exceptions. Going into Thunderbird
3.0, Firefox overhauled its exception mechanism and for a short time
Thunderbird's process required significantly greater user intent to add
an exception. (Preferences, Advanced, Certificates, View Certificates,
Servers, Add Exception.) At this time DreamHost had invalid
certificates, free certificates were not available, invalid certificates
were fairly common, Thunderbird's autoconfig security model already
assumed a reliable network connection, Thunderbird could only run on
desktops/laptops which were more likely to have a secure network, etc.
We relented and Thunderbird ended up where it is now. Thunderbird
immediately displays the Add Security Exception UI; the user only
needs to click Confirm Security Exception. (Noting that Thunderbird's
autoconfig process is significantly more multi-step.)
== Certificate Exception Mechanisms in Platform / Firefox OS
Currently, the only UI affordance to add certificate exceptions is
exposed by the browser app/subystem for HTTPS sites. I assert that this
is a different risk profile and we wouldn't want to follow it blindly
and don't actually want to follow it at all[1].
There are general bugs filed on being able to import a new CA or
certificate at https://bugzil.la/769183 and https://bugzil.la/867899.
Users with adb push access also have the potentially to manually import
certificates from the command line, see
https://groups.google.com/forum/#!msg/mozilla.dev.b2g/B57slgVO3TU/G5TA-PiFI_EJ
It is my understanding that:
* there is only a single certificate store on the device and therefore
that all
Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
Thanks for the overview of a real problem, Andrew. (I recall having to add an exception for a Mozilla Root CA to access email at one time.) Andrew Sutherland writes: I propose that we use a certificate-observatory-style mechanism to corroborate any invalid certificates by attempting the connection from 1 or more trusted servers whose identity can be authenticated using the existing CA infrastructure. Although this can identify a MITM between the mail client and the internet, I assume it won't identify one between the mail server and the internet. *** it looks like you are behind a corporate firewall that MITMs you, you should add the firewall's CA to your device. Send the user to a support page to help walk them through these steps if that seems right. *** it looks like the user is under attack I wonder how to distinguish these two situations and whether they really should be distinguished. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
Andrew, Le 29 mai 2014 à 09:13, Andrew Sutherland asutherl...@asutherland.org a écrit : My imagined rationale for why someone would use a self-signed certificate amounts to laziness. being one of those persons using a self-signed certificate, let's enrich your use cases list ;) I use a self-signed certificate because the server that I'm managing is used by a handful of persons which are part of community. This community can be friends and/or family. The strong link here is the *human trust* in between people, which is higher than the trust of a third party. -- Karl Dubost, Mozilla http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
On 05/28/2014 07:22 PM, Karl Tomlinson wrote: (I recall having to add an exception for a Mozilla Root CA to access email at one time.) It's fairly common that there exist multiple aliases to access a mail server but the server does not have certificates available for all of them. In the specific Mozilla case, this was probably https://bugzil.la/815771. Andrew Sutherland writes: I propose that we use a certificate-observatory-style mechanism to corroborate any invalid certificates by attempting the connection from 1 or more trusted servers whose identity can be authenticated using the existing CA infrastructure. Although this can identify a MITM between the mail client and the internet, I assume it won't identify one between the mail server and the internet. I understand your meaning to be that we won't detect if the mail server's outbound SMTP connections to other domains and inbound SMTP connections from other SMTP servers either support, strongly request, or require use of TLS (likely via STARTTLS upgrade). I confirm the above and that the issue is somewhat orthogonal. This is something we would probably want to do as in-app advocacy via extension/opt-in either by scraping transmission headers or downloading a prepared database and cross-checking. *** it looks like you are behind a corporate firewall that MITMs you, you should add the firewall's CA to your device. Send the user to a support page to help walk them through these steps if that seems right. *** it looks like the user is under attack I wonder how to distinguish these two situations and whether they really should be distinguished. What I imagined here was that the certificate would identify itself as allegedly originating from the given vendor. We could treat that as a sufficient hint using RegExps, or analyze the entire chain to cover cases where the vendor uses their own trust root that we can add to a small database. In the very bad cases where all of the vendor's devices use the same certificate, that's also easy to identify. I think it's a meaningful distinction to make since we are able to tell the user You should be able to talk privately with the mail server, but the network you are using won't let you and wants to hear everything you say. Your options are to use a different network or configure your device to use the proxy. For example, you might want to use cellular data rather than wi-fi or pick a different wi-fi network, like a guest network. I'm not sure it's a must-have-on-first-landing feature, especially since I don't think Firefox OS devices are particularly enterprise friendly right now. For example, in order to actually authenticate MoCo's non-guest wi-fi you need to be able to import the certificate (or add an exception! :) which are what two of those bugs I linked to are about. But I'd want to make sure we could evolve towards supporting that direction better. Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
On 5/28/2014 5:30 PM, Andrew Sutherland wrote: tl;dr: We need to figure out how to safely allow for invalid certificates to be used in the Firefox OS Gaia email app. We do want all users to be able to access their email, but not by compromising the security of all users. Read on if you work in the security field / care about certificates / invalid certificates. Certificate verification failures, I think, can happen for one of the following reasons, sorted by rough order that I expect they happen: * Untrusted CA/self-signed certificate * Domain name mismatch (e.g., a certificate for foobar.mozilla.org is used on site foobar.allizom.org) * Expired certificate * Insufficiently secure certificate (e.g., certificates that violate CA/Browser Forum rules or the like. I don't know if we actually consider this a failure right now, but it's a reasonable distinct failure class IMHO) * Explicitly revoked * Malformed certificate It seems to me that some of these are more tolerable than others. There is a much different risk profile to accepting a certificate that expired two days ago versus one that fails an OCSP validation check. * the exception is per-domain, not per-port, so if we add an exception for port 993 (imaps), that would also impact https. It's per-host:port. I recently had to add a cert override for an NNTPS server by hand. In bug https://bugzil.la/874346 the requirement that is coming from partners is that: - we need to imminently address the certificate exception problem - the user needs to be able to add the exception from the account setup flow. (As opposed to requiring the user to manually go to the settings app and add an exception. At least I think that's the request.) I know you and I discussed this in another context not too long ago, and the common consensus we had agreed then was that doing a non-automatic manual labor to set up the exception was ideal. Requiring it from the account setup flow is... slightly disconcerting to me. == Proposed solution for informed, safe decision-making This is a problem I've been thinking about in a slightly different situation (specifically, for S/MIME certificates). Unfortunately, my blog post containing these thoughts is still in the process of being written, so I can't refer you to that post yet. We have an excellent chance to try to rethink CA infrastructure in this process beyond the notion of a trusted third-party CA system (which is already more or less broken, but that's beside the point). My own views on this matter is that the most effective notion of trust is some sort of key pinning: using a different key is a better indicator of an attack than having a valid certificate; under this model the CA system is largely information about how to trust a key you've never seen before. There is a minor gloss point here in that there are legitimate reasons to need to re-key servers (e.g., Heartbleed or the Debian OpenSSL entropy issue), and I don't personally have the security experience to be able to suggest a solution here. I'm not necessarily asking that we immediately find the best solution right now (particularly given partners' demands for immediacy), but rather that we think about a solution that can eventually be proposed for standardization in appropriate standards bodies, and also that we design a solution that ought to require mostly technical fixes as opposed to architectural redesigns. I know the IETF is currently working on an extension for key pinning in HTTP that may be relevant here: https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/. Another relevant fact for the design future is the eventual introduction of DANE and DNSSEC, which allows the DNS records to indicate the intended keys of TLS connections. That's not feasible for the near future, though, especially as I don't think Mozilla has even started implementing DANE. I propose that we use a certificate-observatory-style mechanism to corroborate any invalid certificates by attempting the connection from 1 or more trusted servers whose identity can be authenticated using the existing CA infrastructure. Doesn't the EFF's SSL Observatory already track the SSL certificates to indicate potential MITMs? For example, if the email app contacts sketchy.example.com and finds the certificate does not validate, I propose that: * TCPSocket/XHR with mozSystem return information on the certificate/chain that we received. I think that, in any case, the exact reason for certificate errors [in terms of the taxonomy I described above] should be returned if validation fails. [ I should also point out that I'm planning on asking the WebCrypto working group about standardizing some certificate stuff--particularly validation--for S/MIME, since I really, really, really don't want to try write an OCSP verifier in JS. The discussion of how to identify certificate details may be relevant for that effort as
Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
On 05/28/2014 08:37 PM, Karl Dubost wrote: Le 29 mai 2014 à 09:13, Andrew Sutherland asutherl...@asutherland.org a écrit : My imagined rationale for why someone would use a self-signed certificate amounts to laziness. being one of those persons using a self-signed certificate, let's enrich your use cases list ;) I use a self-signed certificate because the server that I'm managing is used by a handful of persons which are part of community. This community can be friends and/or family. The strong link here is the *human trust* in between people, which is higher than the trust of a third party. Trusting you as a human doesn't translate into protecting the users of your server from man-in-the-middle attacks. How do you translate the human trust into the technical trust infrastructure supported by Firefox and Thunderbird and the rest of the Internet? Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
Andrew, Le 29 mai 2014 à 09:50, Andrew Sutherland asutherl...@asutherland.org a écrit : Trusting you as a human doesn't translate into protecting the users of your server from man-in-the-middle attacks. How do you translate the human trust into the technical trust infrastructure supported by Firefox and Thunderbird and the rest of the Internet? I was replying to the self-signed certificate == laziness. What I'm saying is that if you have 4 users on your server. You may decide to create a certificate yourself and educate your users about what message the certificate will send to their mail client and teach them why they can accept the warning message in this case. -- Karl Dubost, Mozilla http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
On 5/28/2014 7:13 PM, Andrew Sutherland wrote: My imagined rationale for why someone would use a self-signed certificate amounts to laziness. (We've been unable to determine what the rationale is for using invalid certificates in these cases as of yet.) For example, they install dovecot on Debian/Ubuntu, it generates a self-signed certificate, they're fine with that. Or they created a self-signed certificate years ago before they were free and don't want to update them now. Under this model, it's very unlikely that there's a server farm of servers each using different self-signed certificates, which would be the case where we want multiple certificates. (Such a multi-exception scenario would also not work with my proposed trusted server thing.) Two more possible rationales: 1. The administrator is unwilling to pay for an SSL certificate and unaware of low-cost or free SSL certificate providers. 2. The administrator has philosophical beliefs about CAs, or the CA trust model in general, and is unwilling to participate in it. Neglecting the fact that encouraging click-through behavior of users can only weaken the trust model. [ Discovered in the course of reading a few CACert root certificate request bugs. ] [ Secondary note: most of my thoughts on X.509 certificates are geared towards its relation to S/MIME, which shares similar but not quite identical concerns. ] -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
On 05/28/2014 06:01 PM, Karl Dubost wrote: Andrew, Le 29 mai 2014 à 09:50, Andrew Sutherland asutherl...@asutherland.org a écrit : Trusting you as a human doesn't translate into protecting the users of your server from man-in-the-middle attacks. How do you translate the human trust into the technical trust infrastructure supported by Firefox and Thunderbird and the rest of the Internet? I was replying to the self-signed certificate == laziness. What I'm saying is that if you have 4 users on your server. You may decide to create a certificate yourself and educate your users about what message the certificate will send to their mail client and teach them why they can accept the warning message in this case. But without verifying that the certificate they received is the certificate you created, those users are open to attack. On desktop we unfortunately allowed this to become common. We have an opportunity here to not make the same mistake on mobile. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
On Wed, May 28, 2014 at 5:13 PM, Andrew Sutherland asutherl...@asutherland.org wrote: On 05/28/2014 07:16 PM, David Keeler wrote: * there is only a single certificate store on the device and therefore that all exceptions are device-wide This is an implementation detail - it would not be difficult to change exceptions to per-principal-per-app rather than just per-principal. It's good to know this should be easy, thank you! IIRC, different apps can share a single HTTPS connection. So, for HTTPS, you'd also need to modify the HTTP transaction manager so that it doesn't mix transactions from apps with different cert override settings on the same connection. My imagined rationale for why someone would use a self-signed certificate amounts to laziness. We encourage websites and mail servers to use invalid and self-signed certificates by making it easy to override the cert error. A theoretical (but probably not in reality) advantage of only storing one per domain:port is that in the event the key A is compromised and a new key B is generated, the user would be notified when going back to A from B. This actually happens regularly in real life. If you accumulate all the cert error overrides for a host then you end up permanently letting every captive portal the user has accessed the site through MitM the user. David Keeler wrote: In terms of solving the issue at hand, we have a great opportunity to not implement the press this button to MITM yourself paradigm that desktop browsers currently use. The much safer option is to ask the user for the expected certificate fingerprint. If it matches the certificate the server provided, then the exception can safely be added. The user will have to obtain that fingerprint out-of-band over a hopefully secure channel. David, I would like to agree with you but even I myself have never checked the fingerprint of a certificate before adding a cert error override for a site, and I suspect that implementing the solution you propose would be the equivalent of doing nothing for the vast majority of cases, due to usability issues. I agree this is a safe approach and the trusted server is a significant complication in this whole endeavor. But I can think of no other way to break the symmetry of am I being attacked or do I just use a poorly configured mail server? It would be pretty simple to build a list of mail servers that are known to be using valid TLS certificates. You can build that list through port scanning, in conjunction with the auto-config data you already have. That list could be preloaded into the mail app and/or dynamically retrieved/updated. Even if we seeded this list with only the most common email providers, we'd still be protecting a lot more users than by doing nothing, since email hosting is heavily consolidated and seems to be becoming more consolidated over time. NB: I do think that if we must make it possible to insecurely add a certificate exception, then making it harder for users to do so is desirable. My original hope was that we'd just provide a mechanism in the settings app to let users add exceptions and we'd never link the user directly to this from the email app. Instead we'd bounce them to a support page first which would require a-hassle-but-not-ridiculous steps along the lines of the long flow via Thunderbird preferences. It's unlikely a gmail vanity domain user would decide to actively take all those steps to compromise their security. I don't think that making things difficult for the users of our software is going to improve things too much because users will blame us for being harder to use than our competitors. One way to discourage the use of non-trusted certificates is to have a persistent UI indication that the certificate is bad in the app, along with a link to more info so that the user can learn why using such certificates is a bad idea. This way, even if we make adding cert error overrides easy for users, we're still putting pressure on the server administrator to use a valid certificate. Regarding DANE: Any TLS registry can apply to be a trust anchor in Mozilla's CA program and we'll add them if they meet our requirements. We can constrain them to issuing certificates that are trusted only for their own TLDs; we've done this with some CAs in our program already. Any CA can give away free certificates to any subset of websites (e.g. any website within a TLD). Consequently, there really isn't much different about the CA system we already have and DANE, as far as the trust model or costs are concerned. Cheers, Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
Le 29 mai 2014 à 10:25, David Keeler dkee...@mozilla.com a écrit : But without verifying that the certificate they received is the certificate you created, those users are open to attack. agreed. My intent in the discussion is NOT Let's not verify the certificate is valid but to allow the scenario This self-signed certificate is from blah and we checked it. Basically, to have mechanisms where the trust is not a question of centralization. Centralized trust systems have their own set of weakness and consequences for the infrastructure. -- Karl Dubost, Mozilla http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
