Simply, notaries tell you whether the cert you're seeing is the same cert they're seeing. You then decide on whether that means the site's authenticated.
I agree with the accommodating interpretation given to dremspider's comment, that the SSL we're focused on, web SSL, is practically destroyed by the failure of the CA system.
However, I'm trying to be a little more discerning by pointing out that SSL is one component in security schemes, distinct from the scheme itself, whichever one we're talking about. In web, the security scheme fails if the CA system fails. SSL can still be successfully used in other schemes, as in email, SIP, and VPNs.
Maybe we should be saying HTTPS instead? Still not ideal, but much better than merely saying SSL. Perhaps "web security"?
SSL has been destroyed, not because of protocol problems but because of the companies running the show.
It's the authentication part of the whole scheme that's the issue. Don't conflate SSL with the CA system; they are parts used together in a complete scheme. "SSL" would continue to work if we switched the authentication component to another method like distributed views (notaries).
I don't often tell folks to RTFA, but the amount of uninformed opinion in these SSL discussions is excessive and very counterproductive.
Simply, notaries tell you whether the cert you're seeing is the same cert they're seeing. You then decide on whether that means the site's authenticated.
(Not so simply, the Convergence system is designed extensibly so that notaries can use whatever method they please to return their vote of confidence/no-confidence, be it whether they've seen the cert before, some result from DNSSEC, or even the existing CA system.)
Each notary can use any backend validation method it wants. It could check certs stored in DNSSEC, it could use the existing CA system, the EFF will have one that uses their SSL observatory, etc.
Ah, this must be the convergence aspect of Convergence, allowing different validation techniques through being technique agnostic. Smart move.
(Re notary specification: Perspectives allows you to configure which notaries you wish to use, but the interface is not polished.)
Various DigiNotar intermediate certificates had been cross-signed by other trusted CAs. In order to achieve full blocking, we implemented code which checks for DigiNotar's name in the certificate chain.
I haven't seen website certs with multiple signers. If anyone knows for sure this is possible or has an example to share, please speak up.
Cross-signing IIUC is only when CAs authorize other CAs:
A cross-certificate is a certificate issued by one Certificate Authority (CA) that signs the public key for the root certificate of another Certificate Authority. Cross-certificates provide a means to create a chain of trust from a single, trusted, root CA to multiple other CAs.
(Note, I believe you can sign a CA's intermediate instead of their root; this appears to be what happened with the DigiNotar incident.)
When you say "cross-signed certificate", do you mean website certificates where more than one CA has signed them? I'd thought "cross-signed" or "bridge" certificates were like CA certificates in that they sat in your browser and linked CAs. If that's the case, that's different in a way that doesn't get you the aforementioned value from having multiple CAs sign a single web certificate independently.
If certificates could have multiple signers, we could nix the authority of any one CA and still keep the cert.
An analogous change would be to enable multiple signatures on a single certificate. Recall that a single X.509 certificate contains a public key, a subject, and a signature binding the two together from a CA. There's no reason (in principle) that we couldn't declare a certificate as a public key, a subject, and a set of signatures, each from a different CA. It turns out that there is a proposal for this kind of alternate, multi-signature certificate (using the OpenPGP standard), which i'll talk about later.
I mentioned earlier that there is an alternate proposal — OpenPGP Certificates instead of X.509 certificates — which allows multiple signatures per certificate. The proposal is designed to be implementable in parallel with existing X.509 certificates. However, it is not widely implemented or adopted yet.
Very well, then, "school" does not apply to universities in British English. I think the reasoning is suspect, but I'll accept the conclusion.
When we converse online with others of unknown origins, we may want to be sensitive to dialect differences. As soon as we see we're disagreeing over the meaning of a term we might better clarify what we mean rather than judge the other speech incorrect. Obviously, with dialect differences there is no right or wrong unless one is inclined to look down one's nose at those not speaking the Queen's English which doesn't have the practical benefit of improving communication.
Even outside dialectal disagreement, generally, communication is benefited by people trying to understand one another rather than slavish adherence to one's particular concept of language.
I will say you've done a good job of not taking the argument into needless personal conflict. That's admirable. Admirably British, it seems to me.
That's a very interesting distinction. Certainly touches on an important difference between university and "lower education".
But this is trying to over-specify "school" and "teach" to suit your purpose. In reality, "school" applies to universities, and "teach" applies to lecturing (and advising).
If your gripe is that "school", as you understood it in the context of the article, means "``lower'' education", then that's the point you should make. And I agree with you there -- investigation turns up evidence corroborating that this is what Braben means:
Within a few years, Braben says, every child could own one of these computers from age 11 until graduating high school.
(Quoted from an American publication.)
Be careful about getting lost in details, especially in reflexive defiance of those who contradict you. It drags everyone into the weeds.
I get the impression that how we choose is going to be one of the primary issues going forward.
Currently, Perspectives allows you to specify which notary servers you'd like to use (and what percentage of them must agree (and for how long)).
But how convenient is that? I imagine people might choose notary configurations much like how they subscribe to DNSBLs or choose Ad Block filter subscriptions.
Worse, far from providing increased trust agility, DNSSEC-based systems actually provide reduced trust agility. As unrealistic as it might be, I or a browser vendor do at least have the option of removing VeriSign from the trusted CA database, even if it would break authenticity with some large percentage of sites. With DNSSEC, there is no action that I or a browser vendor could take which would change the fact that VeriSign controls the.com TLD.
If we sign up to trust these people, we're expecting them to willfully behave forever, without any incentives at all to keep them from misbehaving. The closer you look at this process, the more reminiscent it becomes. Sites create certificates, those certificates are signed by some marginal third party, and then clients have to accept those signatures without ever having the option to choose or revise who we trust. Sound familiar?
The browser CA model is screwed up. DNSSEC is screwed up. What's the answer?
I think Marlinspike was smart to start with defining the problem. And now, with Convergence, he's also trying to address it. Check it out. (And check out Perspectives. Perspectives is the project he based Convergence on.)
With HTTPS, the people you trust are the few hundreds of CAs your browser is configured to trust. It's way too many, and your vulnerability with them is a logical OR -- any CA fails and you are vulnerable. It's a fucked up system. However, at least you can remove DigiNotar from your browser's trusted list.
With DNSSEC, you trust the root. They are your "trust anchor". And you get no choice about it.
Each system is fucked up.
This relates to the concept of "trust agility" that Marlinspike discussed. He wrote it up in a blog entry. I highly recommend reading it and understanding it. You can get to the blog by the first link in this Slashdot article a couple weeks ago.
I get them from a secret site on the internet.... [LMGTFY]
Your uncharitable reading of my question and the implications in your reply leave me to take umbrage. Now I'm inclined to be less kind in response. I'll assume instead you're just being silly rather than making a sincere statement with how you phrased your response.
When I went shopping around for DNSBLs, I had several criteria I judged by like "how do the lists get populated?" So I wonder now, how do the IPs on Keith Parkansky's list, the one you base your DROPs on, get there?
Looks like he gets his information from Okean.com and Wizcrafts.net, with no mention of how the two sources are merged. Neither of those sources states how it gets its information. Maybe you have relationships with them so you know more than the websites reveal? I would be uncomfortable giving control over my firewall configuration to so vague third parties.
Thanks for bringing this up. Every time we talk about SSL issues folks fail to bring up the notaries-based systems. (Even during the last/. article, which was really about Marlinspike's Convergence.)
Additional information: Convergence is based on Perspectives.
Network notaries let you see a diverse views of the public key(s) used by an HTTPS server over time.
That "someone" may have better said "the Internet is full of threat". My blocked ports log says there's an unauthorized attempt every 2 and a half minutes. That's not counting attacks on 25, 53, and 80.
My system is plenty secure, but I guess you could refer the the net at large as "insecure as living fuck".
Slashdot Mirror
Simply, notaries tell you whether the cert you're seeing is the same cert they're seeing. You then decide on whether that means the site's authenticated.
It's in the video.
I agree with the accommodating interpretation given to dremspider's comment, that the SSL we're focused on, web SSL, is practically destroyed by the failure of the CA system.
However, I'm trying to be a little more discerning by pointing out that SSL is one component in security schemes, distinct from the scheme itself, whichever one we're talking about. In web, the security scheme fails if the CA system fails. SSL can still be successfully used in other schemes, as in email, SIP, and VPNs.
Maybe we should be saying HTTPS instead? Still not ideal, but much better than merely saying SSL. Perhaps "web security"?
(Or, more obviously, the use of multiple views (from multiple notaries) helps you to converge on authenticity.)
SSL has been destroyed, not because of protocol problems but because of the companies running the show.
It's the authentication part of the whole scheme that's the issue. Don't conflate SSL with the CA system; they are parts used together in a complete scheme. "SSL" would continue to work if we switched the authentication component to another method like distributed views (notaries).
I don't often tell folks to RTFA, but the amount of uninformed opinion in these SSL discussions is excessive and very counterproductive.
Simply, notaries tell you whether the cert you're seeing is the same cert they're seeing. You then decide on whether that means the site's authenticated.
(Not so simply, the Convergence system is designed extensibly so that notaries can use whatever method they please to return their vote of confidence/no-confidence, be it whether they've seen the cert before, some result from DNSSEC, or even the existing CA system.)
Each notary can use any backend validation method it wants. It could check certs stored in DNSSEC, it could use the existing CA system, the EFF will have one that uses their SSL observatory, etc.
Ah, this must be the convergence aspect of Convergence, allowing different validation techniques through being technique agnostic. Smart move.
(Re notary specification: Perspectives allows you to configure which notaries you wish to use, but the interface is not polished.)
Various DigiNotar intermediate certificates had been cross-signed by other trusted CAs. In order to achieve full blocking, we implemented code which checks for DigiNotar's name in the certificate chain.
http://blog.gerv.net/2011/09/diginotar-compromise/
Implemented code to compensate for the DigiNotar chaining?
Stark example of how the current model is well and truly fucked.
I haven't seen website certs with multiple signers. If anyone knows for sure this is possible or has an example to share, please speak up.
Cross-signing IIUC is only when CAs authorize other CAs:
A cross-certificate is a certificate issued by one Certificate Authority (CA) that signs the public key for the root certificate of another Certificate Authority. Cross-certificates provide a means to create a chain of trust from a single, trusted, root CA to multiple other CAs.
(Note, I believe you can sign a CA's intermediate instead of their root; this appears to be what happened with the DigiNotar incident.)
Where did you find the registrar for The Register? The whois information I get says
When you say "cross-signed certificate", do you mean website certificates where more than one CA has signed them? I'd thought "cross-signed" or "bridge" certificates were like CA certificates in that they sat in your browser and linked CAs. If that's the case, that's different in a way that doesn't get you the aforementioned value from having multiple CAs sign a single web certificate independently.
If certificates could have multiple signers, we could nix the authority of any one CA and still keep the cert.
An analogous change would be to enable multiple signatures on a single certificate. Recall that a single X.509 certificate contains a public key, a subject, and a signature binding the two together from a CA. There's no reason (in principle) that we couldn't declare a certificate as a public key, a subject, and a set of signatures, each from a different CA. It turns out that there is a proposal for this kind of alternate, multi-signature certificate (using the OpenPGP standard), which i'll talk about later.
I mentioned earlier that there is an alternate proposal — OpenPGP Certificates instead of X.509 certificates — which allows multiple signatures per certificate. The proposal is designed to be implementable in parallel with existing X.509 certificates. However, it is not widely implemented or adopted yet.
http://lair.fifthhorseman.net/~dkg/tls-centralization/
That is, if we're bothering with CAs in the future, instead of notaries (e.g. Perspectives or Convergence) or some other technology.
I guess the system is pretty fucked up if this is a valid concern.
Very well, then, "school" does not apply to universities in British English. I think the reasoning is suspect, but I'll accept the conclusion.
When we converse online with others of unknown origins, we may want to be sensitive to dialect differences. As soon as we see we're disagreeing over the meaning of a term we might better clarify what we mean rather than judge the other speech incorrect. Obviously, with dialect differences there is no right or wrong unless one is inclined to look down one's nose at those not speaking the Queen's English which doesn't have the practical benefit of improving communication.
Even outside dialectal disagreement, generally, communication is benefited by people trying to understand one another rather than slavish adherence to one's particular concept of language.
I will say you've done a good job of not taking the argument into needless personal conflict. That's admirable. Admirably British, it seems to me.
I had just learned about what Facebook had been doing by reading GameBoyRMH's sig:
Facebook's pure HTML tracking system - How long has this been going on?
That's a very interesting distinction. Certainly touches on an important difference between university and "lower education".
But this is trying to over-specify "school" and "teach" to suit your purpose. In reality, "school" applies to universities, and "teach" applies to lecturing (and advising).
If your gripe is that "school", as you understood it in the context of the article, means "``lower'' education", then that's the point you should make. And I agree with you there -- investigation turns up evidence corroborating that this is what Braben means:
Within a few years, Braben says, every child could own one of these computers from age 11 until graduating high school.
(Quoted from an American publication.)
Be careful about getting lost in details, especially in reflexive defiance of those who contradict you. It drags everyone into the weeds.
I get the impression that how we choose is going to be one of the primary issues going forward.
Currently, Perspectives allows you to specify which notary servers you'd like to use (and what percentage of them must agree (and for how long)).
But how convenient is that? I imagine people might choose notary configurations much like how they subscribe to DNSBLs or choose Ad Block filter subscriptions.
Brilliant! Thanks.
"He's resorting to name calling, which means he's wrong" is itself an ad hominem.
Public key crypto is not the same thing as the current browser HTTPS CA trust model. Make the distinction and you'll be better able to understand him.
SSL And The Future Of Authenticity, Moxie Marlinspike:
Worse, far from providing increased trust agility, DNSSEC-based systems actually provide reduced trust agility. As unrealistic as it might be, I or a browser vendor do at least have the option of removing VeriSign from the trusted CA database, even if it would break authenticity with some large percentage of sites. With DNSSEC, there is no action that I or a browser vendor could take which would change the fact that VeriSign controls the .com TLD.
If we sign up to trust these people, we're expecting them to willfully behave forever, without any incentives at all to keep them from misbehaving. The closer you look at this process, the more reminiscent it becomes. Sites create certificates, those certificates are signed by some marginal third party, and then clients have to accept those signatures without ever having the option to choose or revise who we trust. Sound familiar?
The browser CA model is screwed up. DNSSEC is screwed up. What's the answer?
I think Marlinspike was smart to start with defining the problem. And now, with Convergence, he's also trying to address it. Check it out. (And check out Perspectives. Perspectives is the project he based Convergence on.)
With HTTPS, the people you trust are the few hundreds of CAs your browser is configured to trust. It's way too many, and your vulnerability with them is a logical OR -- any CA fails and you are vulnerable. It's a fucked up system. However, at least you can remove DigiNotar from your browser's trusted list.
With DNSSEC, you trust the root. They are your "trust anchor". And you get no choice about it.
Each system is fucked up.
This relates to the concept of "trust agility" that Marlinspike discussed. He wrote it up in a blog entry. I highly recommend reading it and understanding it. You can get to the blog by the first link in this Slashdot article a couple weeks ago.
I get them from a secret site on the internet.... [LMGTFY]
Your uncharitable reading of my question and the implications in your reply leave me to take umbrage. Now I'm inclined to be less kind in response. I'll assume instead you're just being silly rather than making a sincere statement with how you phrased your response.
When I went shopping around for DNSBLs, I had several criteria I judged by like "how do the lists get populated?" So I wonder now, how do the IPs on Keith Parkansky's list, the one you base your DROPs on, get there?
Looks like he gets his information from Okean.com and Wizcrafts.net, with no mention of how the two sources are merged. Neither of those sources states how it gets its information. Maybe you have relationships with them so you know more than the websites reveal? I would be uncomfortable giving control over my firewall configuration to so vague third parties.
The attack appears to have been targeting Gmail users specifically.
Okay, then, more relevantly, multiple views on Gmail's certificate.
That'll give you a good idea if someone's MITMing you.
Thanks for bringing this up. Every time we talk about SSL issues folks fail to bring up the notaries-based systems. (Even during the last /. article, which was really about Marlinspike's Convergence.)
Additional information: Convergence is based on Perspectives.
Network notaries let you see a diverse views of the public key(s) used by an HTTPS server over time.
As an example, here are multiple views of Google's SSL.
Interesting. Where do you get the list? And at what rate does it change?
Moving ports protects against worms.
That "someone" may have better said "the Internet is full of threat". My blocked ports log says there's an unauthorized attempt every 2 and a half minutes. That's not counting attacks on 25, 53, and 80.
My system is plenty secure, but I guess you could refer the the net at large as "insecure as living fuck".