9 ms·

CA Security Council – Myths about CA's

21 points by andygambles 12y ago

andygambles 12y ago
Is the CA Security Council doing a good job of providing information about what they do and why we should still trust CA's?
pilif 12y ago
>As are subject to various checks and balances, including third-party qualified audits through WebTrust or ETSI and strict criteria set forth by leading browsers, before they are accepted in browser root stores. yes. And in cases like DigiNotar and other less famous CA (and intermediate) compromises, we've seen how well that works.
oleganza 12y ago
Remember that CAs were invented as a way to solve two UX and security issues: 1. When I go to google.com, I want to be sure it's the same google.com everyone else connects to. 2. When I go to google.com many more times, I want to get to the same google.com as I was visiting before. It's relatively easy to do #2 (SSH was doing it for years), but it's very hard task to do #1 correctly. The first problem is essentially a problem of global consensus. It can only be solved using Bitcoin blockchain, poorly simulated with Certificate Authorities, or left alone as SSH did (which is fine for hackers connecting to their own machines, but not fine for global name system). If anyone is interested in improving SSL/TLS, the way forward is to use blockchain to associate names and public keys so that users could know for sure that they connect to the same name as anyone else without trusting any CAs. Of course, that'd require development not only of a new DNS-meets-SSL protocol, but also robust lightweight Bitcoin nodes and correct UX conventions. That's hard, time consuming, but the only way forward out of the current mess. Relevant quote from Nick Szabo ("leaving small holes unplugged"): http://blog.oleganza.com/post/69174500046/leaving-small-holes-unplugged http://blog.oleganza.com/post/69174500046/leaving-small-hole...
- valarauca1 12y ago
  >It can only be solved using Bitcoin blockchain Could you please elaborate?
  - oleganza 12y ago
    Proving that you see the same data as everyone else is Byzantine General's Problem which cannot be solved in information theory. However, it can be solved practically if there's a single hugely powerful chain of proofs-of-work referencing that data. Today it is Bitcoin's blockchain. What you want to prove to yourself is that if "google.com" is associated with public key "04cafebabe", that association is also visible to everyone else (provided other people follow the same protocol). The distributed DNS+SSL protocol could look like this (simplified): 1) To register a name "google.com", check that it's not registered yet (see below). If not, create a special Bitcoin transaction ("registration tx") that encodes both the name and the public key of the SSL certificate used by that server. 2) To check who owns the name "google.com", find the earliest "registration tx" on the blockchain (other people could add more, but only the first one is considered valid). If the name is 100 blocks deep, trust the public key associated with it. The protocol can (and should be) extended to allow transferring the name to new public keys, you may check how Namecoin does it. What you get in result is that every single user can be sure that they see the same up-to-date public key identifying "google.com" without any trusted Certificate Authorities who have failed at this promise multiple times already. As a nice side effect, name allocation and trade is also decentralized. If you own name "google.com" and users respect the protocol, no one can take this name from you or censor your sale of that name to someone else. Also, you are free to register your own name without asking for anyone's permission and paying fees.
    - valarauca1 12y ago
      The fundamental problem is the first come first name nature. It is not correct. If I monitor DNS changes, and when new host names pop up. If I have the resources I can make a block-chain transaction automatically. How will my transactions (provided I also create a new walletID) for each transaction be framed as fraudulent? Without community or authoritative over-site?
- peterwwillis 12y ago
  Practically nothing you said is correct. * CAs were implemented to issue and verify digital certificates, not verify a connection. No part of TLS PKI is intended to verify that you are connecting to the same service everyone else is. PKI (and CAs) are intended to assure identity, as well as providing a secure connection over a public network. When you buy a Papa Johns pizza, we know we're not all buying our pizza from the exact same Papa Johns store. But we do know it's a Papa Johns. * SSH does do your second example, but TLS PKI does not. As the above example points out, there is more than one Papa Johns store, just as there is more than one web server or service around the globe providing the same organization's data. SSH assumes there is only one Papa Johns store that serves all Papa Johns pizzas; one host is tied to one host key signature. PKI does not make this assumption. * Blockchains are a stupid idea because they require access to a global public network. Depending on DNS to issue and verify digital certificates is like using SMTP/POP3 to 'simplify' the authentication of users when distributing web downloads. TLS PKI does not require access to a network, nor receiving any updates from it, and its software is designed to be secure by default, unlike DNS, which in many operating systems cannot be secure by design (because they don't provide a verifying stub resolver, besides the inherent security problems in the protocol's design). Honestly, most of the suggestions people have to replace PKI just reduces reliability without providing particularly improved security. The biggest problem with PKI is the uncertainty of ensuring the security of such a high number of CAs. That's easy enough to solve... have less CAs and make them more transparent.
tptacek 12y ago
This is truly impressive. Nine "myths" presented, of which eight are self-evidently true. The only thing on this page that anyone can credibly argue about is whether SSL/TLS is so antiquated that it demands a ground-up replacement.
- ghshephard 12y ago
  Obviously you know 1000x more about this than I do, so I'm interesting in your take on: "CAs do not provide value". Is it really the case that anyone can get a CA to issue a certificate for "Wellsfargo.com?" Doesn't the CA provide some level of value to the consumer, that they really are connecting to someone who was able to prove they have control over the "wellsfargo" domain, or at least their DNS server? And, likewise, doesn't the CA provide some level of value to the Bank, who wants the nice "Green Lock" appearing in the URL bar? Nobody is arguing that the system is bulletproof, that all consumers are educated to watch for a "green" HTTPS connection, and that 100% of certificates have always been assigned to the proper party, and only the proper party - but, by and large, isn't the job of a CA (and the value that they offer), to provide some level of assurance that you really are connecting to the website that you think you are connecting to? And, haven't they provided a lot of that value over the last decade or so?
  - iancarroll 12y ago
    No. Wells Fargo is on every CA's high risk list. Even if you were able to pass the validation for the domain it would be flagged and you would have to go through a lot more checks.
  - michaelbuckbee 12y ago
    SSL/TLS Certs are trying to deal with two separate problems: 1. Over the wire encryption - where most of the criticisms in this thread are focused. Which I will also defer to tptacek's knowledge. 2. Site identification as an anti-phishing mechanism. For even the cheapest certs (domain+email validated) - the CAs will reject SSL cert requests for anything that might be a phishing target. Detecting "wellsfargo.com" is pretty easy, where it gets tricky is things like "wellsforgo.com", "wellsfàrgo.com" etc. This has even gotten weird as the browser makers have started to really de-emphasize domain certs vs ev certs (cheap vs expensive), to the point where in most cases now having a domain cert does not know green at all. Screenshots: https://www.expeditedssl.com/pages/visual-security-browser-ssl-icons-and-design https://www.expeditedssl.com/pages/visual-security-browser-s...
peterwwillis 12y ago
Highly amusing that a security council refers to the technology it oversees using a name that was replaced 14 years ago because it was considered too insecure (and the IETF wanted their own name)
- iancarroll 12y ago
  They're used interchangeably pretty much everywhere.
  - deleted 12y ago
    [deleted]
  - peterwwillis 12y ago
    Don't you think that's just stupid, though? First of all they're not the same things at all, secondly nobody actually uses SSL 3.0, and third it's now broken due to POODLE. TLS rocks, SSL sucks. Yet we keep saying SSL when we mean TLS.
    - iancarroll 12y ago
      Do I think its stupid? Yeah. But honestly, it's used so people don't ask "what's that?". I don't think it undermines someone's credibility.
      - peterwwillis 12y ago
        This is a page that purports to dispel misconceptions about the industry's core technology. This would probably be the perfect place to add a section called "I heard SSL is broken because <list of obsolete flaws in SSL>".
AlyssaRowan 12y ago
The big elephant in the room is the intermediate certificates; conveniently unaddressed in this glib "everything's fine" piece. Everything's not fine. We're only just beginning to tackle deep-seated problems in TLS and improve things, but we're probably stuck with some of the most regrettable decisions, like x.509 and the CAs. We need Certificate Transparency most of all for intermediates. The roots may be small in number, and many of them a little outdated, but the number of still-unaccounted-for intermediates worries me. How many have no path and/or usage restriction? Who has them? Are they all regulated? Because they should be. Some are likely in the hands of attackers. We should be accounting for them all. The CA model, as it stands today, is inferior to DNSSEC for DV. Yes, under DNSSEC, those above you in the chain of authority can fake DNS responses, but at least no-one else can. If the DNS root is removed from the control of a potential attacker (not that they'd ever get away with it, but still) then I view DANE pinning as strictly superior to DV certificates (although still not perfect, but nor is DNS). The CA model may still have use with EV. The problem of a transparency equivalent for DNSSEC remains unsolved, and is under tension with it being considered a bad thing to be able to enumerate domains and hosts (although it is in practice very practical to do so anyway).
- iancarroll 12y ago
  Mozilla addresses this problem by requiring all CAs to disclose every intermediary certificate they've issued. CT will hopefully become widespread, given Chrome will kill EV indicators without it.
  - andygambles 12y ago
    Chrome is practically forcing CA's to adopt CT by removing green address bars for non-CT certs.
contingencies 12y ago
"Hi, we're an association of all the people making money from x. Let us tell you why the highly appealing x, responsible for saving the world from evil daemons, should remain in widespread use despite extensive evidence to the contrary." "Those of us providing x are really doing it well, and have to pass stringent checks, but those are too complex to go in to so please accept my hand-waving in lieu of actual evidence." "We've been providing x for so long, obviously we're great at it and it's something that needs to keep being provided." "We have different flavors of x, by the way: choose from vanilla, rainbow, or secure cookies and cream!" "We go to conferences and sometimes talk to people. This makes us really important and stuff. Are you impressed yet?" "Despite there nominally being 600 providers of x, in practice only 65 are 'in the club', and 7 of us have formed an international cartel!" "Some of us somewhat recently twiddled some configuration bits, therefore we are clearly on top of this x-manufacturing technology stuff." "It's true! Our reputation, as x providers in the lucrative cartel, is of critical importance. We've even paid someone to draft this drivel. Are you convinced yet?" "It's not true what those people say - 'Once you take x there's no going back' - you can vomit, have your stomach pumped, or induce psychosis or hypnosis for the duration of the undesired effects. Of course, you can't get anything done for that period of time, which may occur at the worst possible moment: when booking a plane ticket, making a critical banking transaction, or communicating about the human rights abuses of your government. But that's OK, because there's clearly a way to turn off our pervasive control of your 'highly secure' communications... right?"
zobzu 12y ago
Load of bs with some truth to it but avoiding to mention whats important. As per cab forum rules the 3rd party audit is about having scripts for generation, a determined (by yourself) set of ppl during ceremony.... Which you can tape and send to a paid auditor of your choice. Thats the only check/balance made. The rest is in the same vein. Sounds good until you know the details. Then it doesnt sound all that safe or great anymore - more of a money making machine. Turns out this site is made to defend these financial interests.

21 points by andygambles 12y ago

Is the CA Security Council doing a good job of providing information about what they do and why we should still trust CA's?

pilif 12y ago

>As are subject to various checks and balances, including third-party qualified audits through WebTrust or ETSI and strict criteria set forth by leading browsers, before they are accepted in browser root stores. yes. And in cases like DigiNotar and other less famous CA (and intermediate) compromises, we've seen how well that works.

oleganza 12y ago

Remember that CAs were invented as a way to solve two UX and security issues: 1. When I go to google.com, I want to be sure it's the same google.com everyone else connects to. 2. When I go to google.com many more times, I want to get to the same google.com as I was visiting before. It's relatively easy to do #2 (SSH was doing it for years), but it's very hard task to do #1 correctly. The first problem is essentially a problem of global consensus. It can only be solved using Bitcoin blockchain, poorly simulated with Certificate Authorities, or left alone as SSH did (which is fine for hackers connecting to their own machines, but not fine for global name system). If anyone is interested in improving SSL/TLS, the way forward is to use blockchain to associate names and public keys so that users could know for sure that they connect to the same name as anyone else without trusting any CAs. Of course, that'd require development not only of a new DNS-meets-SSL protocol, but also robust lightweight Bitcoin nodes and correct UX conventions. That's hard, time consuming, but the only way forward out of the current mess. Relevant quote from Nick Szabo ("leaving small holes unplugged"): http://blog.oleganza.com/post/69174500046/leaving-small-holes-unplugged http://blog.oleganza.com/post/69174500046/leaving-small-hole...

valarauca1 12y ago
>It can only be solved using Bitcoin blockchain Could you please elaborate?
- oleganza 12y ago
  Proving that you see the same data as everyone else is Byzantine General's Problem which cannot be solved in information theory. However, it can be solved practically if there's a single hugely powerful chain of proofs-of-work referencing that data. Today it is Bitcoin's blockchain. What you want to prove to yourself is that if "google.com" is associated with public key "04cafebabe", that association is also visible to everyone else (provided other people follow the same protocol). The distributed DNS+SSL protocol could look like this (simplified): 1) To register a name "google.com", check that it's not registered yet (see below). If not, create a special Bitcoin transaction ("registration tx") that encodes both the name and the public key of the SSL certificate used by that server. 2) To check who owns the name "google.com", find the earliest "registration tx" on the blockchain (other people could add more, but only the first one is considered valid). If the name is 100 blocks deep, trust the public key associated with it. The protocol can (and should be) extended to allow transferring the name to new public keys, you may check how Namecoin does it. What you get in result is that every single user can be sure that they see the same up-to-date public key identifying "google.com" without any trusted Certificate Authorities who have failed at this promise multiple times already. As a nice side effect, name allocation and trade is also decentralized. If you own name "google.com" and users respect the protocol, no one can take this name from you or censor your sale of that name to someone else. Also, you are free to register your own name without asking for anyone's permission and paying fees.
  - valarauca1 12y ago
    The fundamental problem is the first come first name nature. It is not correct. If I monitor DNS changes, and when new host names pop up. If I have the resources I can make a block-chain transaction automatically. How will my transactions (provided I also create a new walletID) for each transaction be framed as fraudulent? Without community or authoritative over-site?
peterwwillis 12y ago
Practically nothing you said is correct. * CAs were implemented to issue and verify digital certificates, not verify a connection. No part of TLS PKI is intended to verify that you are connecting to the same service everyone else is. PKI (and CAs) are intended to assure identity, as well as providing a secure connection over a public network. When you buy a Papa Johns pizza, we know we're not all buying our pizza from the exact same Papa Johns store. But we do know it's a Papa Johns. * SSH does do your second example, but TLS PKI does not. As the above example points out, there is more than one Papa Johns store, just as there is more than one web server or service around the globe providing the same organization's data. SSH assumes there is only one Papa Johns store that serves all Papa Johns pizzas; one host is tied to one host key signature. PKI does not make this assumption. * Blockchains are a stupid idea because they require access to a global public network. Depending on DNS to issue and verify digital certificates is like using SMTP/POP3 to 'simplify' the authentication of users when distributing web downloads. TLS PKI does not require access to a network, nor receiving any updates from it, and its software is designed to be secure by default, unlike DNS, which in many operating systems cannot be secure by design (because they don't provide a verifying stub resolver, besides the inherent security problems in the protocol's design). Honestly, most of the suggestions people have to replace PKI just reduces reliability without providing particularly improved security. The biggest problem with PKI is the uncertainty of ensuring the security of such a high number of CAs. That's easy enough to solve... have less CAs and make them more transparent.

tptacek 12y ago

This is truly impressive. Nine "myths" presented, of which eight are self-evidently true. The only thing on this page that anyone can credibly argue about is whether SSL/TLS is so antiquated that it demands a ground-up replacement.

ghshephard 12y ago
Obviously you know 1000x more about this than I do, so I'm interesting in your take on: "CAs do not provide value". Is it really the case that anyone can get a CA to issue a certificate for "Wellsfargo.com?" Doesn't the CA provide some level of value to the consumer, that they really are connecting to someone who was able to prove they have control over the "wellsfargo" domain, or at least their DNS server? And, likewise, doesn't the CA provide some level of value to the Bank, who wants the nice "Green Lock" appearing in the URL bar? Nobody is arguing that the system is bulletproof, that all consumers are educated to watch for a "green" HTTPS connection, and that 100% of certificates have always been assigned to the proper party, and only the proper party - but, by and large, isn't the job of a CA (and the value that they offer), to provide some level of assurance that you really are connecting to the website that you think you are connecting to? And, haven't they provided a lot of that value over the last decade or so?
- iancarroll 12y ago
  No. Wells Fargo is on every CA's high risk list. Even if you were able to pass the validation for the domain it would be flagged and you would have to go through a lot more checks.
- michaelbuckbee 12y ago
  SSL/TLS Certs are trying to deal with two separate problems: 1. Over the wire encryption - where most of the criticisms in this thread are focused. Which I will also defer to tptacek's knowledge. 2. Site identification as an anti-phishing mechanism. For even the cheapest certs (domain+email validated) - the CAs will reject SSL cert requests for anything that might be a phishing target. Detecting "wellsfargo.com" is pretty easy, where it gets tricky is things like "wellsforgo.com", "wellsfàrgo.com" etc. This has even gotten weird as the browser makers have started to really de-emphasize domain certs vs ev certs (cheap vs expensive), to the point where in most cases now having a domain cert does not know green at all. Screenshots: https://www.expeditedssl.com/pages/visual-security-browser-ssl-icons-and-design https://www.expeditedssl.com/pages/visual-security-browser-s...

peterwwillis 12y ago

Highly amusing that a security council refers to the technology it oversees using a name that was replaced 14 years ago because it was considered too insecure (and the IETF wanted their own name)

iancarroll 12y ago
They're used interchangeably pretty much everywhere.
- deleted 12y ago
  [deleted]
- peterwwillis 12y ago
  Don't you think that's just stupid, though? First of all they're not the same things at all, secondly nobody actually uses SSL 3.0, and third it's now broken due to POODLE. TLS rocks, SSL sucks. Yet we keep saying SSL when we mean TLS.
  - iancarroll 12y ago
    Do I think its stupid? Yeah. But honestly, it's used so people don't ask "what's that?". I don't think it undermines someone's credibility.
    - peterwwillis 12y ago
      This is a page that purports to dispel misconceptions about the industry's core technology. This would probably be the perfect place to add a section called "I heard SSL is broken because <list of obsolete flaws in SSL>".

AlyssaRowan 12y ago

The big elephant in the room is the intermediate certificates; conveniently unaddressed in this glib "everything's fine" piece. Everything's not fine. We're only just beginning to tackle deep-seated problems in TLS and improve things, but we're probably stuck with some of the most regrettable decisions, like x.509 and the CAs. We need Certificate Transparency most of all for intermediates. The roots may be small in number, and many of them a little outdated, but the number of still-unaccounted-for intermediates worries me. How many have no path and/or usage restriction? Who has them? Are they all regulated? Because they should be. Some are likely in the hands of attackers. We should be accounting for them all. The CA model, as it stands today, is inferior to DNSSEC for DV. Yes, under DNSSEC, those above you in the chain of authority can fake DNS responses, but at least no-one else can. If the DNS root is removed from the control of a potential attacker (not that they'd ever get away with it, but still) then I view DANE pinning as strictly superior to DV certificates (although still not perfect, but nor is DNS). The CA model may still have use with EV. The problem of a transparency equivalent for DNSSEC remains unsolved, and is under tension with it being considered a bad thing to be able to enumerate domains and hosts (although it is in practice very practical to do so anyway).

iancarroll 12y ago
Mozilla addresses this problem by requiring all CAs to disclose every intermediary certificate they've issued. CT will hopefully become widespread, given Chrome will kill EV indicators without it.
- andygambles 12y ago
  Chrome is practically forcing CA's to adopt CT by removing green address bars for non-CT certs.

contingencies 12y ago

"Hi, we're an association of all the people making money from x. Let us tell you why the highly appealing x, responsible for saving the world from evil daemons, should remain in widespread use despite extensive evidence to the contrary." "Those of us providing x are really doing it well, and have to pass stringent checks, but those are too complex to go in to so please accept my hand-waving in lieu of actual evidence." "We've been providing x for so long, obviously we're great at it and it's something that needs to keep being provided." "We have different flavors of x, by the way: choose from vanilla, rainbow, or secure cookies and cream!" "We go to conferences and sometimes talk to people. This makes us really important and stuff. Are you impressed yet?" "Despite there nominally being 600 providers of x, in practice only 65 are 'in the club', and 7 of us have formed an international cartel!" "Some of us somewhat recently twiddled some configuration bits, therefore we are clearly on top of this x-manufacturing technology stuff." "It's true! Our reputation, as x providers in the lucrative cartel, is of critical importance. We've even paid someone to draft this drivel. Are you convinced yet?" "It's not true what those people say - 'Once you take x there's no going back' - you can vomit, have your stomach pumped, or induce psychosis or hypnosis for the duration of the undesired effects. Of course, you can't get anything done for that period of time, which may occur at the worst possible moment: when booking a plane ticket, making a critical banking transaction, or communicating about the human rights abuses of your government. But that's OK, because there's clearly a way to turn off our pervasive control of your 'highly secure' communications... right?"

zobzu 12y ago

Load of bs with some truth to it but avoiding to mention whats important. As per cab forum rules the 3rd party audit is about having scripts for generation, a determined (by yourself) set of ppl during ceremony.... Which you can tape and send to a paid auditor of your choice. Thats the only check/balance made. The rest is in the same vein. Sounds good until you know the details. Then it doesnt sound all that safe or great anymore - more of a money making machine. Turns out this site is made to defend these financial interests.