9 ms·

Firefox 32 Supports Public Key Pinning

188 points by jonchang 12y ago

cornewut 12y ago
Maybe FF and Google should just become CAs? It would remove the extra step as currently both pinning and registering with existing CA are required?
- bottled_poe 12y ago
  Why should we trust them?
  - belorn 12y ago
    With the current setup, people are trusting mozilla/google to: Give you the correct software, Update silently, Determine which CA certificates to trust by default, and Determine which certificates are valid by pinning. The CA is trusted to do: Determine which certificates are valid.
    - tokenizerrr 12y ago
      Not really. For firefox anyone can build from source (see also iceweasel), disable automatic updates. For chrome it's mostly the same, but then for Chromium instead.
      - unfamiliar 12y ago
        Can you verify that the binary download of Firefox is compiled from that source unmodified?
        gluxon 12y ago
        There's work in progress to allow this. https://bugzilla.mozilla.org/show_bug.cgi?id=885777 https://bugzilla.mozilla.org/show_bug.cgi?id=885777
      - belorn 12y ago
        For people who build from source, all control is at the user. They are responsible for the security, and they do not need to trust anyone. The question about who should have trust invested in them do not involve them, as they operate outside the system.
      - drdaeman 12y ago
        Just building from source doesn't guarantee anything. Firefox is giant. It shouldn't be hard for a malicious party — should one appear someday — to hide some tiny backdoor somewhere in a more-than-a-hundred-megabyte source code tarball. Verifying GPG signatures of the tarball could prevent some (but not all) issues, but from my observations it's rarely done. And when I've seen it done public key's origin wasn't thoroughly verified, just blindly `gpg --recv-keys`'d from keyserver.
        xorcist 12y ago
        This comes up again and again. Sure, the individual users is unlikely to wade through the complete delta for every published version, but it's not uncommon for packagers to be involved upstream as well (with a few unfortunate outliers of course). Backdoors have been catched this way before.
        drdaeman 12y ago
        There's a difference between "building from source" and "obtaining software from a trusted party". Your suggestion (trusting the packagers) implies the latter and is almost irrelevant to the former. If one trusts a team to catch possible issues, one may trust the binary this team builds as well.
  - logicallee 12y ago
    Yes, why should we trust our browser company with the security of our SSL connections. That's like locking your car with a key made by the company that manufactured it!
- Maakuth 12y ago
  That must be a legal minefield as they'd then be in competition with established CAs that use their browser as sort of a platform (unfair competition or something). Being a CA also seems to be a messy business, I don't now if Mozilla would have the resources to do that. Google seems to have a CA of their own, but they don't seem to be signing certificates other than their own with it.
  - tptacek 12y ago
    I've been told by people on those teams that the legal issues behind this (or any other interference with the CA system) is a big concern.
- lucb1e 12y ago
  They are. Google for sure, and Mozilla maintains a list of them that ships with Firefox. If that isn't the ultimate level of trust (deciding which CAs your browser will trust) then I don't know what is.
  - tptacek 12y ago
    Both Google and Mozilla have their hands in some ways tied about which CAs they support. Their browsers have to work on the Internet as it is, not the Internet as they want it, and so both certainly include CAs that their owners would prefer they didn't. Also, of course, there's the fact that both Mozilla and Google give their users control over which CAs they include. The UI for that functionality is unfortunate. But on the other hand, if generalist developers really want to stick it to NSA, that's a good project they can work on without screwing over users with bad cryptography.
xroche 12y ago
What about DANE (http://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities http://en.wikipedia.org/wiki/DNS-based_Authentication_of_Nam...) ?
- pilif 12y ago
  When you support DANE, you trust the various governments responsible for the various country domains to not wanting to MITM owners of said domains. I'm sure everybody has a different subset of governments they would be putting in the "trustworthy" bucket and it's not up to the browser vendors to make a political statement there. Browser vendors would have to trust all governments equally and AFAIK, none of them have publicly stated what their policies regarding MITMing DNSsec is, nor how well they protect their DNSsec signing keys. CAs have to follow quite rigorous protocols if they want to be included in the browser default list and they have all financial incentives to comply. Governments don't have to follow anything and even if they had, they have all the incentives not to comply. This is why DANE, while otherwise sounding like a really good idea, is ultimately doomed to failure. No browser wants to take responsibility for less-than-stellarly performing governments and no browser wants to make a political statement by only supporting DANE for certain top level domains but not others.
  - Qantourisc 12y ago
    Suppose you could use both normal PKI + DANE ? This way you both need a signed certificate and a MITM for DNSsec. Also in some cases, DANE is "enough". (Unless they start to MITM all websites.)
  - exo762 12y ago
    CA model is broken (>500 of CAs, race to the bottom in terms of price, security is not a part of their business model). DANE is no better. What we really want is to be able to withdraw trust. There is no point for me to trust some Iranian CA. Why should I want to trust one? Today - I have to trust it, because you can't just remove CA without breaking a percentage of websites for you. And you can't normally erase CA from existence, because on single CA rely many customers and each of them will have broken website. Please read about Convergence by Moxie Marlinspike. It solves the removing of trust problem.
cpeterso 12y ago
The problem I've run into with public key pinning is captive portals. Mobile operating systems or browsers need to provide a better user experience for captive portals.
- nandhp 12y ago
  My solution to that is to open http://example.com/ http://example.com/ (instead of, e.g. Google) after connecting to Wi-Fi. It doesn't use SSL (so it works) and I have little use for it the rest of the time (so if the Firefox DNS cache gets messed up, it doesn't matter).
- kijin 12y ago
  Don't captive portals already have a problem with every HTTPS website? I don't see why PK pinning would cause any problem that doesn't already exist.
  - illumen 12y ago
    Yeah, many captive portals do have a problem with HTTPS. From my experience in 50+ hotels in the last years.
    - kijin 12y ago
      Which is not surprising at all, since the whole point of HTTPS is to prevent anyone other than Google from displaying a valid web page at https://www.google.com/ https://www.google.com/ If a captive portal is able to display a valid web page when you try to visit an HTTPS website, that would be a serious red flag.
- giovannibajo1 12y ago
  iOS have had good user experience for captive portals since a long time (iOS 3 I think), and also Mac OSX. They automatically detect when a captive portal is present by doing a background connection to some Apple-owned property and trying to download a small text file; if it fails for any reason, they bring up a modal panel showing the captive portal and letting the user login; then, they detect when the Internet access is active and close the panel (or, lately, let the user close the panel with a "Finish" button). What's more important is that the whole operating system / applications are not given the signal "network is on" until the whole process is finished, so you don't get one dozen of failures from applications that try to refresh in background and can't access their backend servers. This said, I really hate the fact that the WiFi alliance has left us in this very sad state. Like many similar committees, they move too slowly; captive portals arose from a real-world problem that wasn't solved by the WiFi standard, so people had to come up with weird DNS/HTTP interceptions that fail in so many regards it's not even funny. If there's somebody to blame, it's not operating systems for not adding weird heuristics like Apple did, but Wifi Alliance for not bringing to the market a good solution for handling hotspots soon enough.
zdw 12y ago
I wish that this sort of stuff would come down to API-level interfaces. For example, for the longest time Python's SSL library wouldn't even verify SSL certs: https://wiki.python.org/moin/SSL https://wiki.python.org/moin/SSL And would gladly connect to MITM'ed sites. I think this is rectified, but the information I've found is conflicting. It seems to me that securing API endpoints would be even more important than end users, as there's could be a much larger quantity of data through an API than a browser.
- ayrx 12y ago
  If you are making SSL requests with Python you will want to use service_identity[0] to perform certificate validation. Hynek has some good information on his blog[1]. [0]: https://github.com/pyca/service_identity https://github.com/pyca/service_identity [1]: https://hynek.me/talks/tls/ https://hynek.me/talks/tls/
- giovannibajo1 12y ago
  Python's SSL state has been worse than other languages because of the 2.x -> 3.x transition, so basically 2.7 was left broken for longer than ideal. Eventually, they decided to backport most of the network security improvements (http://legacy.python.org/dev/peps/pep-0466/ http://legacy.python.org/dev/peps/pep-0466/), see there the timeline. Notice that this applies to the standard library; many people use the requests library which not only offers a superior API but also more security by default.
jbb555 12y ago
Yeah, makes sense. I guess. But I'm more and more worried about the web "platform", it just gets more and more complex each day.
mkal_tsr 12y ago
> Other mechanisms, such as a client-side pre-loaded Known Pinned Host list MAY also be used. Fantastic addition IMO. You could distribute/sync hash lists on and offline, awesome.
StavrosK 12y ago
Does anyone know why they didn't go with TACK?
- eplsaft 12y ago
  TACK is a TLS extension. It must be added to TLS 1.3 RFC.
  - StavrosK 12y ago
    I see, thanks.
  - tptacek 12y ago
    TACK doesn't have to be added to any RFC in order for browsers to adopt it. They could have integrated TACK, but chose not to. I wish they'd go the other way on that.
    - danudey 12y ago
      Sure, unless you want a standardized interface that everyone can reliably implement. Once it's in the RFC, people can start implementing it, but if you implement before there's a published standard then you're stuck with a broken implementation, or you break backwards-compatibility.
      - eli 12y ago
        It wouldn't be the first RFC to begin life as an implementation instead of a spec document.
        tptacek 12y ago
        Which is the right way for an RFC to begin!
        deleted 12y ago
        [deleted]
lucb1e 12y ago
I wonder how this is going to work. I've been using an add-on to pin certificates for a half a year now and it's a hell on some websites. It nicely worked for my bank for a while, but they now employ the same technique as Google, Twitter, Facebook, Akamai, etc., changing certificates and even their CA seemingly at random. You'd think I'm being MITM'd but I'm pretty sure that's not actually the case. Edit: I should read more closely, found it: > the list of acceptable certificate authorities must be set at time of build for each pinned domain. So it's directly in Firefox' source code right now. Pretty much useless for anyone but a few big sites. And the pinning RFC doesn't sound much better. It makes the client store something about sites they visited, which roughly translates to supercookies.
- Someone1234 12y ago
  > And the pinning RFC doesn't sound much better. It makes the client store something about sites they visited, which roughly translates to supercookies. I don't follow. If the user visits a site for the first time (ever) over a secure connection, they will become much more resilient to MITM for all future connections (including the ones where it updates). That's a win in my book. At least it is a win from the "hacker" MiTM threat. It won't be as useful against states/governments since there might never be a secure connection ever. But I'd take a solution NOW that works-ish than a solution maybe never which is flawless. Security in depth and all that jazz. The ultimate solution is some kind of secure DNS infrastructure which delivers information about HTTP certificates (which I believe is in the works also).
  - lucb1e 12y ago
    I'm not saying it's entirely bad, but it's something some users will want to disable for privacy concerns. The current model works well enough to allow widespread online banking and although this RFC will certainly make it more secure, there are also disadvantages. I happen to know that Chrome hardcodes a list of EV certificates (or at least I read so a while ago), it could do the same for CAs. Or the browser could ask a central server which CA belongs to a certificate fingerprint. Not that different from OSCP except that it'll probably be run by the browser manufacturer instead of the CA.
eplsaft 12y ago
this sounds identical to google CRLSet. Basically a list of pinned certs inside source code. > In the future, we would like to support dynamic pinsets rather than relying on built-in ones. HTTP Public Key Pinning (HPKP) [1] is an HTTP header that allows sites to announce their pinset. ok cool. Requires initial safe connection once. Like HSTS.
- reedloden 12y ago
  This is nothing like Google CRLSet. CRLSet is just a way of collecting the CRLs from a ton of different CAs and having a way to push those out to Chrome browsers easily without users having to individually download them all from the CAs. Chrome has its own TLS pinning implementation that basically works the same way as Firefox's. See https://src.chromium.org/chrome/trunk/src/net/http/transport_security_state_static.json https://src.chromium.org/chrome/trunk/src/net/http/transport...
tete 12y ago
Meanwhile Chrome doesn't even support OCSP (Certificate Revocation) for performance reasons, not even after Heartbleed. I hope that doesn't sound like fanboyism, but not being able to communicate a certificate revocation properly is worrisome.
- tptacek 12y ago
  That's because OCSP doesn't work. The real-world Internet routinely breaks OCSP queries, which results in Firefox (and other browsers) soft-failing them: if OCSP doesn't work, the browser goes ahead with the connection. The security problem here is trivially observed. TLS certificate revocation is a mess. We know what the solution will look like: it'll be something like HSTS, except that instead of caching "this site must use HTTPS", we'll also cache "this site must use OCSP stapling", and the OCSP data will be conveyed in-band in the HTTPS connection. It's hard to ding Chrome for not supporting something that doesn't really exist yet. So, no: not "for performance reasons". Incidentally: Chrome more or less invented certificate pinning.
  - tete 12y ago
    But OCSP is the only thing that's widely supported as of now. You can't on one hand say "don't blame Chrome to not support something that doesn't exist", when at the same time it rejects something that's widely deployed and even is considered a requirement for CAs. Being able to revoke your certificate, even if it has problems is better than not being able to. OCSP is still the standard way of communicating certificate revocations and even with all the HTTP-Extensions you need a way for certificate revocation. Unlike most alternatives OCSP is out of the box supported by IE, Firefox, Opera and Safari. Only Chrome has it disabled per default. Most people revoked their old certificates after Heartbleed. This is an example of where you need an alternative to just pinning a key. So you are saying that an attacker has to make sure that the OCSP connection isn't working means OCSP is worse than having no possibility of certificate revocation at all? Not saying that it's absolutely secure. Hopefully everyone knows that there are flaws in HTTPS/SSL. Zooko's triangle[1] even gives you a hint why. Also I am curious. What better, more widely used way of Certificate Revocation do you know? [1] https://en.wikipedia.org/wiki/Zooko%27s_triangle https://en.wikipedia.org/wiki/Zooko%27s_triangle
deleted 12y ago
[deleted]

188 points by jonchang 12y ago

Maybe FF and Google should just become CAs? It would remove the extra step as currently both pinning and registering with existing CA are required?

bottled_poe 12y ago
Why should we trust them?
- belorn 12y ago
  With the current setup, people are trusting mozilla/google to: Give you the correct software, Update silently, Determine which CA certificates to trust by default, and Determine which certificates are valid by pinning. The CA is trusted to do: Determine which certificates are valid.
  - tokenizerrr 12y ago
    Not really. For firefox anyone can build from source (see also iceweasel), disable automatic updates. For chrome it's mostly the same, but then for Chromium instead.
    - unfamiliar 12y ago
      Can you verify that the binary download of Firefox is compiled from that source unmodified?
      - gluxon 12y ago
        There's work in progress to allow this. https://bugzilla.mozilla.org/show_bug.cgi?id=885777 https://bugzilla.mozilla.org/show_bug.cgi?id=885777
    - belorn 12y ago
      For people who build from source, all control is at the user. They are responsible for the security, and they do not need to trust anyone. The question about who should have trust invested in them do not involve them, as they operate outside the system.
    - drdaeman 12y ago
      Just building from source doesn't guarantee anything. Firefox is giant. It shouldn't be hard for a malicious party — should one appear someday — to hide some tiny backdoor somewhere in a more-than-a-hundred-megabyte source code tarball. Verifying GPG signatures of the tarball could prevent some (but not all) issues, but from my observations it's rarely done. And when I've seen it done public key's origin wasn't thoroughly verified, just blindly `gpg --recv-keys`'d from keyserver.
      - xorcist 12y ago
        This comes up again and again. Sure, the individual users is unlikely to wade through the complete delta for every published version, but it's not uncommon for packagers to be involved upstream as well (with a few unfortunate outliers of course). Backdoors have been catched this way before.
        drdaeman 12y ago
        There's a difference between "building from source" and "obtaining software from a trusted party". Your suggestion (trusting the packagers) implies the latter and is almost irrelevant to the former. If one trusts a team to catch possible issues, one may trust the binary this team builds as well.
- logicallee 12y ago
  Yes, why should we trust our browser company with the security of our SSL connections. That's like locking your car with a key made by the company that manufactured it!
Maakuth 12y ago
That must be a legal minefield as they'd then be in competition with established CAs that use their browser as sort of a platform (unfair competition or something). Being a CA also seems to be a messy business, I don't now if Mozilla would have the resources to do that. Google seems to have a CA of their own, but they don't seem to be signing certificates other than their own with it.
- tptacek 12y ago
  I've been told by people on those teams that the legal issues behind this (or any other interference with the CA system) is a big concern.
lucb1e 12y ago
They are. Google for sure, and Mozilla maintains a list of them that ships with Firefox. If that isn't the ultimate level of trust (deciding which CAs your browser will trust) then I don't know what is.
- tptacek 12y ago
  Both Google and Mozilla have their hands in some ways tied about which CAs they support. Their browsers have to work on the Internet as it is, not the Internet as they want it, and so both certainly include CAs that their owners would prefer they didn't. Also, of course, there's the fact that both Mozilla and Google give their users control over which CAs they include. The UI for that functionality is unfortunate. But on the other hand, if generalist developers really want to stick it to NSA, that's a good project they can work on without screwing over users with bad cryptography.

xroche 12y ago

What about DANE (http://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities http://en.wikipedia.org/wiki/DNS-based_Authentication_of_Nam...) ?

pilif 12y ago
When you support DANE, you trust the various governments responsible for the various country domains to not wanting to MITM owners of said domains. I'm sure everybody has a different subset of governments they would be putting in the "trustworthy" bucket and it's not up to the browser vendors to make a political statement there. Browser vendors would have to trust all governments equally and AFAIK, none of them have publicly stated what their policies regarding MITMing DNSsec is, nor how well they protect their DNSsec signing keys. CAs have to follow quite rigorous protocols if they want to be included in the browser default list and they have all financial incentives to comply. Governments don't have to follow anything and even if they had, they have all the incentives not to comply. This is why DANE, while otherwise sounding like a really good idea, is ultimately doomed to failure. No browser wants to take responsibility for less-than-stellarly performing governments and no browser wants to make a political statement by only supporting DANE for certain top level domains but not others.
- Qantourisc 12y ago
  Suppose you could use both normal PKI + DANE ? This way you both need a signed certificate and a MITM for DNSsec. Also in some cases, DANE is "enough". (Unless they start to MITM all websites.)
- exo762 12y ago
  CA model is broken (>500 of CAs, race to the bottom in terms of price, security is not a part of their business model). DANE is no better. What we really want is to be able to withdraw trust. There is no point for me to trust some Iranian CA. Why should I want to trust one? Today - I have to trust it, because you can't just remove CA without breaking a percentage of websites for you. And you can't normally erase CA from existence, because on single CA rely many customers and each of them will have broken website. Please read about Convergence by Moxie Marlinspike. It solves the removing of trust problem.

cpeterso 12y ago

The problem I've run into with public key pinning is captive portals. Mobile operating systems or browsers need to provide a better user experience for captive portals.

nandhp 12y ago
My solution to that is to open http://example.com/ http://example.com/ (instead of, e.g. Google) after connecting to Wi-Fi. It doesn't use SSL (so it works) and I have little use for it the rest of the time (so if the Firefox DNS cache gets messed up, it doesn't matter).
kijin 12y ago
Don't captive portals already have a problem with every HTTPS website? I don't see why PK pinning would cause any problem that doesn't already exist.
- illumen 12y ago
  Yeah, many captive portals do have a problem with HTTPS. From my experience in 50+ hotels in the last years.
  - kijin 12y ago
    Which is not surprising at all, since the whole point of HTTPS is to prevent anyone other than Google from displaying a valid web page at https://www.google.com/ https://www.google.com/ If a captive portal is able to display a valid web page when you try to visit an HTTPS website, that would be a serious red flag.
giovannibajo1 12y ago
iOS have had good user experience for captive portals since a long time (iOS 3 I think), and also Mac OSX. They automatically detect when a captive portal is present by doing a background connection to some Apple-owned property and trying to download a small text file; if it fails for any reason, they bring up a modal panel showing the captive portal and letting the user login; then, they detect when the Internet access is active and close the panel (or, lately, let the user close the panel with a "Finish" button). What's more important is that the whole operating system / applications are not given the signal "network is on" until the whole process is finished, so you don't get one dozen of failures from applications that try to refresh in background and can't access their backend servers. This said, I really hate the fact that the WiFi alliance has left us in this very sad state. Like many similar committees, they move too slowly; captive portals arose from a real-world problem that wasn't solved by the WiFi standard, so people had to come up with weird DNS/HTTP interceptions that fail in so many regards it's not even funny. If there's somebody to blame, it's not operating systems for not adding weird heuristics like Apple did, but Wifi Alliance for not bringing to the market a good solution for handling hotspots soon enough.

zdw 12y ago

I wish that this sort of stuff would come down to API-level interfaces. For example, for the longest time Python's SSL library wouldn't even verify SSL certs: https://wiki.python.org/moin/SSL https://wiki.python.org/moin/SSL And would gladly connect to MITM'ed sites. I think this is rectified, but the information I've found is conflicting. It seems to me that securing API endpoints would be even more important than end users, as there's could be a much larger quantity of data through an API than a browser.

ayrx 12y ago
If you are making SSL requests with Python you will want to use service_identity[0] to perform certificate validation. Hynek has some good information on his blog[1]. [0]: https://github.com/pyca/service_identity https://github.com/pyca/service_identity [1]: https://hynek.me/talks/tls/ https://hynek.me/talks/tls/
giovannibajo1 12y ago
Python's SSL state has been worse than other languages because of the 2.x -> 3.x transition, so basically 2.7 was left broken for longer than ideal. Eventually, they decided to backport most of the network security improvements (http://legacy.python.org/dev/peps/pep-0466/ http://legacy.python.org/dev/peps/pep-0466/), see there the timeline. Notice that this applies to the standard library; many people use the requests library which not only offers a superior API but also more security by default.

jbb555 12y ago

Yeah, makes sense. I guess. But I'm more and more worried about the web "platform", it just gets more and more complex each day.

mkal_tsr 12y ago

> Other mechanisms, such as a client-side pre-loaded Known Pinned Host list MAY also be used. Fantastic addition IMO. You could distribute/sync hash lists on and offline, awesome.

StavrosK 12y ago

Does anyone know why they didn't go with TACK?

eplsaft 12y ago
TACK is a TLS extension. It must be added to TLS 1.3 RFC.
- StavrosK 12y ago
  I see, thanks.
- tptacek 12y ago
  TACK doesn't have to be added to any RFC in order for browsers to adopt it. They could have integrated TACK, but chose not to. I wish they'd go the other way on that.
  - danudey 12y ago
    Sure, unless you want a standardized interface that everyone can reliably implement. Once it's in the RFC, people can start implementing it, but if you implement before there's a published standard then you're stuck with a broken implementation, or you break backwards-compatibility.
    - eli 12y ago
      It wouldn't be the first RFC to begin life as an implementation instead of a spec document.
      - tptacek 12y ago
        Which is the right way for an RFC to begin!
        deleted 12y ago
        [deleted]

lucb1e 12y ago

I wonder how this is going to work. I've been using an add-on to pin certificates for a half a year now and it's a hell on some websites. It nicely worked for my bank for a while, but they now employ the same technique as Google, Twitter, Facebook, Akamai, etc., changing certificates and even their CA seemingly at random. You'd think I'm being MITM'd but I'm pretty sure that's not actually the case. Edit: I should read more closely, found it: > the list of acceptable certificate authorities must be set at time of build for each pinned domain. So it's directly in Firefox' source code right now. Pretty much useless for anyone but a few big sites. And the pinning RFC doesn't sound much better. It makes the client store something about sites they visited, which roughly translates to supercookies.

Someone1234 12y ago
> And the pinning RFC doesn't sound much better. It makes the client store something about sites they visited, which roughly translates to supercookies. I don't follow. If the user visits a site for the first time (ever) over a secure connection, they will become much more resilient to MITM for all future connections (including the ones where it updates). That's a win in my book. At least it is a win from the "hacker" MiTM threat. It won't be as useful against states/governments since there might never be a secure connection ever. But I'd take a solution NOW that works-ish than a solution maybe never which is flawless. Security in depth and all that jazz. The ultimate solution is some kind of secure DNS infrastructure which delivers information about HTTP certificates (which I believe is in the works also).
- lucb1e 12y ago
  I'm not saying it's entirely bad, but it's something some users will want to disable for privacy concerns. The current model works well enough to allow widespread online banking and although this RFC will certainly make it more secure, there are also disadvantages. I happen to know that Chrome hardcodes a list of EV certificates (or at least I read so a while ago), it could do the same for CAs. Or the browser could ask a central server which CA belongs to a certificate fingerprint. Not that different from OSCP except that it'll probably be run by the browser manufacturer instead of the CA.

eplsaft 12y ago

this sounds identical to google CRLSet. Basically a list of pinned certs inside source code. > In the future, we would like to support dynamic pinsets rather than relying on built-in ones. HTTP Public Key Pinning (HPKP) [1] is an HTTP header that allows sites to announce their pinset. ok cool. Requires initial safe connection once. Like HSTS.

reedloden 12y ago
This is nothing like Google CRLSet. CRLSet is just a way of collecting the CRLs from a ton of different CAs and having a way to push those out to Chrome browsers easily without users having to individually download them all from the CAs. Chrome has its own TLS pinning implementation that basically works the same way as Firefox's. See https://src.chromium.org/chrome/trunk/src/net/http/transport_security_state_static.json https://src.chromium.org/chrome/trunk/src/net/http/transport...

tete 12y ago

Meanwhile Chrome doesn't even support OCSP (Certificate Revocation) for performance reasons, not even after Heartbleed. I hope that doesn't sound like fanboyism, but not being able to communicate a certificate revocation properly is worrisome.

tptacek 12y ago
That's because OCSP doesn't work. The real-world Internet routinely breaks OCSP queries, which results in Firefox (and other browsers) soft-failing them: if OCSP doesn't work, the browser goes ahead with the connection. The security problem here is trivially observed. TLS certificate revocation is a mess. We know what the solution will look like: it'll be something like HSTS, except that instead of caching "this site must use HTTPS", we'll also cache "this site must use OCSP stapling", and the OCSP data will be conveyed in-band in the HTTPS connection. It's hard to ding Chrome for not supporting something that doesn't really exist yet. So, no: not "for performance reasons". Incidentally: Chrome more or less invented certificate pinning.
- tete 12y ago
  But OCSP is the only thing that's widely supported as of now. You can't on one hand say "don't blame Chrome to not support something that doesn't exist", when at the same time it rejects something that's widely deployed and even is considered a requirement for CAs. Being able to revoke your certificate, even if it has problems is better than not being able to. OCSP is still the standard way of communicating certificate revocations and even with all the HTTP-Extensions you need a way for certificate revocation. Unlike most alternatives OCSP is out of the box supported by IE, Firefox, Opera and Safari. Only Chrome has it disabled per default. Most people revoked their old certificates after Heartbleed. This is an example of where you need an alternative to just pinning a key. So you are saying that an attacker has to make sure that the OCSP connection isn't working means OCSP is worse than having no possibility of certificate revocation at all? Not saying that it's absolutely secure. Hopefully everyone knows that there are flaws in HTTPS/SSL. Zooko's triangle[1] even gives you a hint why. Also I am curious. What better, more widely used way of Certificate Revocation do you know? [1] https://en.wikipedia.org/wiki/Zooko%27s_triangle https://en.wikipedia.org/wiki/Zooko%27s_triangle

deleted 12y ago

[deleted]