If I get a chance, I'll try to apply the recent attacks by Rizzo et al. on TLS compression and the compressed stream over TLS equivalent by Prado et al., since I like >compression but I also send credentials over TLS :)

I guess you are referring to CRIME/BEAST, right? I haven't had a deep look into those, but it seems they require plaintext injection. In the context of WebSocket (using compression, and with transport over TLS), that would mean injecting WebSocket messages with chosen payload into the conversation between client and server. What I don't get: unless at least one of the endpoints have been compromised, how are you going to inject? And if an endpoint has been compromised, one might as well just grab the unencrypted stuff right away. What am I missing? /Tobias

On 02:51 pm, tobias.oberstein@tavendo.de wrote:

...

.. , since I like compression but I also send credentials over TLS :)

IMHO, credentials should never be sent over the wire (be it encrypted or not) and never be stored in plaintext.

FWIW, Autobahn provides a challenge-response authentication scheme ("WAMP_CRA") that also allows for salted/hashed passwords (pbkdf2-based) for WebSocket/WAMP.

With TLS, and in a Post-Snowden era, how do you know your TLS server isn't impersonated and encryption broken?

Personally, I assume root CA private keys of any CA vendor are owned by the NSA anyway.

There's no rule that says you have to use a "root CA" signed certificate for your TLS connections. Jean-Paul

Really, TLS is broken.

We need a new scheme. For encryption session keys, Diffie-Hellman is available, and provides perfect forward secrecy naturally.

For authentication, we need a peer-based system like PGP has, not relying on centrally managed trust.

I know. Not going to happen any time soon ..

/Tobias

On 6 Oct, 11:02 pm, tobias.oberstein@tavendo.de wrote:

...

...

Personally, I assume root CA private keys of any CA vendor are owned by the NSA anyway.

There's no rule that says you have to use a "root CA" signed certificate for your TLS connections.

Sure, in theory, but there are multiple practical problems when using self-signed certs or certs signed by a CA not built into browsers. As a starter, here are 3:

- enterprise networks might block those right away with no way for the user to accept self-signed or import alien CA certs - the user experience is bad: Firefox scares with dialogs and multiple steps of overcoming those - with WebSocket, browers will not even show a dialog! WebSocket are so called "subresources", and browsers will never render dialogs for these

So in practice, I _have_ to use a CA that is built into all major browsers.

You're assuming a lot here. Perhaps TLS is broken for all the uses you're interested in - that doesn't mean it's broken for everyone else's uses. *This* is probably now sufficiently off-topic, though... Jean-Paul

/Tobias

...

Jean-Paul

...

Really, TLS is broken.

We need a new scheme. For encryption session keys, Diffie-Hellman is available, and provides perfect forward secrecy naturally.

For authentication, we need a peer-based system like PGP has, not relying on centrally managed trust.

I know. Not going to happen any time soon ..

/Tobias

_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

...

...

So in practice, I _have_ to use a CA that is built into all major browsers.

...

You're assuming a lot here.  Perhaps TLS is broken for all the uses you're interested in - that doesn't mean it's broken for everyone else's uses.

@Jean-Paul: Granted .. good catch. My interest is the Web/browser, and also non-browser clients working in a Web-compatible way.

Tobias, all of the things you've said here about browser UI, enterprise networks, and key management tooling are true; however, note that none of those nouns are "TLS".

@Glyph: I agree: "browser UI" is formally unrelated to TLS I (mostly) agree: locked down enterprise networks are orthogonal to TLS - formally. And the "key management" system being ortho to TLS: a very good point. The problem is X.509, and TLS today uses only that, but it is capable of using different schemes in principle. I did some further looking around: turns out there is TLS-PGP http://tools.ietf.org/html/rfc6091 Does someone know whether OpenSSL supports that? [Sidenote: if not, one more reason why a pure Python TLS implementation (then with RFC6091) would rock. The other reason being the total awesomeness of the OpenSSL codebase;) And the third: PyPy.]

 1. Write some code that uses TLS (which is a wire protocol, after all, not a trust model or set of trust roots, nor a key management UI) and addresses these issues, by implementing a new trust model, protocol for exchanging trust roots, or key management UI, and selecting appropriate ciphers.  2. Write some code that uses a brand new wire protocol with unknown, unaudited security properties, also implementing appropriate ciphers, and also implementing all of the things in point 1.

One of these options seems obviously superior to me :-).

Yeah;) 1) => RFC6091

...

*This* is probably now sufficiently off-topic, though...

Man, are there some kind of Topic Police everyone is worried about? Do I need to start taking extra precautions when I write to mailing lists? :-)

Got it. It's just that different communities have different social codes. But it's good that Twisted has no "Topic Police". I like that .. term and fact;)

I think this is on-topic enough, since this might inform TLS work with Twisted in the future, and Vertex has been brought under the Twisted umbrella recently, https://github.com/twisted/vertex and it seeks to provide a different trust model with TLS and Twisted.

Is there any intro / architecture document? I'd like to read more .. /Tobias

On 10/07/2013 09:50 AM, Phil Mayers wrote:

Right now, none are useful in a browser, but personally I have high hopes for raw keys, trust-anchored by DNSSEC via RFC 6698. In this model, X.509 is essentially just a payload format for certs

Sorry, "payload format for keys".

On 07/10/13 11:56, Donald Stufft wrote:

DNSSEC solves none of the problems with the CA system. It just moves the problem around.

Disagree. However - there are other, better forums to have this argument in (and to be frank, I've no interest in having it at all) so I won't respond further. I would however urge other people reading this to look into the issues and decide for themselves.

On 07/10/2013 18:58, Glyph wrote:

If you have a disagreement, please say /what the disagreement is/ (not just "disagree") and then link to resources instead of abstractly claiming people may find them themselves somehow. You don't have to get into a big back-and-forth, but I believe DNSSEC implementation work is proceeding in Twisted so it would be good for the community to be aware of these issues.

Ok. Don't say I didn't warn you. Apologies to anyone who forces themselves to read all this, and please note I DO NOT claim authority on any of this - I'm just a random guy. People should decide for themselves. Donald wrote: """ DNSSEC solves none of the problems with the CA system. It just moves the problem around. """ I believe I understand why he said this, but I think it's incorrect to say that DNSSEC solves "none" of the problems. I think it solves many (though not all) of them, and that supplementary systems - which are desirable in and of themselves - can take us the rest of the way. Here's my reasoning: I think it's fair to say that the PKIX trust model is known to have some serious flaws. They basically stem from the existence of far, far too many CAs, and the lack of constraint on what a CA can issue for. There are various proposed solutions to this problem. DNSSEC-signed TLSA records (DANE; RFC 6698) offer one solution to the problem - to put hashes of certs/keys or issuer/chain certs/keys in DNS, and sign then with DNSSEC. This accomplishes two things: 1. Reduction in the number of trusted CAs. To what degree depends on what deployment model you use - you can put a specific key/cert into DNS, or one or more traditional X.509 issuers that allowed to sign for you. The latter in particular seems likely to be common - reduce the CAs that can sign for "blah.example.com" from ~1500 by putting the hashes of the 1/2/N "good" CA certs (most specific parent!) into the "blah.example.com" TLSA records. 2. Constraint - a DNS zone-signing key can only sign records below it, terminating at secure child delegations (DS keys). The obvious objection to this solution is the necessary trust in the DNS root / parent zones. There are, it seems, people who are not willing to grant this trust. I understand that - particularly in light of recent revelations. However: government agencies are not the only people who might want to get certs in the name of a 3rd party. Crime syndicates attacking the latest race-to-the-bottom CA to get "e<some unicode glyph like x>ample.com" certs are a real issue, and DANE can handle these just fine. There are arguments that DANE moves the trust problem from CAs to registrars and registries. I must admit, I don't understand the threat model here - it's asserted that registrars are cheap&cheerful (true) but they only handle public key material, and don't run the DNS; the registry is a more fruitful target, but validation of the public key material they publish for you is trivial (whereas proving that a CA somewhere hasn't signed a cert for your domain is not). In short, I think it's a significant net win, and as a side benefit offers greatly reduced key management burden. The ability to publish and revoke TLSA records at significantly lower cost than X.509 cert issuance, and without need to interact with a 3rd party, would be valuable even without the above. It could in theory help decouple TLS from X.509 - useful if you want to move to PGP, for example. However, some people don't agree. Moxie Marlinspike discusses the general issues and makes an argument against DANE - see: http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/ ...and the video of the talk here: http://www.youtube.com/watch?v=Z7Wl2FW2TcA He essentially suggests a trusted notary system - a working implementation of which you can see here: http://convergence.io/ I agree that this approach is promising. I am not super-confident that it will take off - end-users literally DO NOT CARE about these issues until it's too late - but if someone (Chrome, Firefox) starts bundling notary functionality and prompting users to trust one or more of a (randomly shuffled) set of notaries on startup, it might... However, I'm not sure how likely that is - see: https://www.imperialviolet.org/2011/09/07/convergence.html [Note Adam Langley is "Google TLS person"] For an alternative take on the problem, see: http://www.certificate-transparency.org/ People interested in reading a pro-DNSSEC PoV should look here (warning - sequence of posts): http://dankaminsky.com/2010/12/13/dnssec-ch1/ ...and here: http://www.slideshare.net/dakami/black-opspki-2 So - not as short as I'd like, but as short as I could make it. I hope that makes my position clear. Finally a note on why I was reluctant to respond... In my experience, "discussions" on TLS, X.509, DNS and DNSSEC can become very emotive, very quickly. There are people who care very, very deeply about the minutae of these issues because they directly impact the politics of privacy and symmetry of access to the internet. To be honest, I lack the mental drive to engage in those discussions over the internet. Face to face might be another matter, but I have better things to do with my time than argue with strangers. So - if anyone is sitting there bouncing up and down in their seat excited about how wrong I am - forgive me if I don't reply, I'm just not as excited about it. Look me up in real life sometime and we'll chat about it over beer! Cheers, Phil

On Oct 7, 2013, at 4:10 PM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:

On 07/10/2013 18:58, Glyph wrote:

...

If you have a disagreement, please say /what the disagreement is/ (not just "disagree") and then link to resources instead of abstractly claiming people may find them themselves somehow. You don't have to get into a big back-and-forth, but I believe DNSSEC implementation work is proceeding in Twisted so it would be good for the community to be aware of these issues.

Ok. Don't say I didn't warn you. Apologies to anyone who forces themselves to read all this, and please note I DO NOT claim authority on any of this - I'm just a random guy. People should decide for themselves.

Donald wrote:

""" DNSSEC solves none of the problems with the CA system. It just moves the problem around. """

I believe I understand why he said this, but I think it's incorrect to say that DNSSEC solves "none" of the problems. I think it solves many (though not all) of them, and that supplementary systems - which are desirable in and of themselves - can take us the rest of the way.

I think I basically agree with this sentiment. A lot of security measures are based on threat-neutralization, whereas DNSSEC is based on threat-reduction. It mitigates intrusions by certain classes of bad actor while still enabling others. An important thing is that the average user isn't going to perceive any difference in security when using DNSSEC; so they're not going to get a false sense of security from DNSSEC.

Here's my reasoning:

I think it's fair to say that the PKIX trust model is known to have some serious flaws. They basically stem from the existence of far, far too many CAs, and the lack of constraint on what a CA can issue for.

One minor quibble I have here is that trust is always between two parties. The presence of a "trusted third party" is _always_ a problem. So it's not that there are too many CAs, but rather, that you *always* need a cartel CA to sign your stuff in order to be able to trust someone, and once you have an established trust relationship, you can't base things off of that relationship rather than off of software-distributor (i.e. browser-vendor) granted authority.

There are various proposed solutions to this problem. DNSSEC-signed TLSA records (DANE; RFC 6698) offer one solution to the problem - to put hashes of certs/keys or issuer/chain certs/keys in DNS, and sign then with DNSSEC. This accomplishes two things:

1. Reduction in the number of trusted CAs. To what degree depends on what deployment model you use - you can put a specific key/cert into DNS, or one or more traditional X.509 issuers that allowed to sign for you. The latter in particular seems likely to be common - reduce the CAs that can sign for "blah.example.com" from ~1500 by putting the hashes of the 1/2/N "good" CA certs (most specific parent!) into the "blah.example.com" TLSA records.

2. Constraint - a DNS zone-signing key can only sign records below it, terminating at secure child delegations (DS keys).

The obvious objection to this solution is the necessary trust in the DNS root / parent zones. There are, it seems, people who are not willing to grant this trust. I understand that - particularly in light of recent revelations.

It's worth noting, however, that you are already accepting a certain degree of trust in the DNS root. Even if your traffic is totally cryptographically secure, if you're talking to a compromised DNS they can still reliably tell (A) who you are talking to and (B) when you are talking to them. So if the option is "trust the DNS and a bunch of CAs" or "trust the DNS", just trusting the DNS is safer (even if not, in an absolute sense, "safe").

However: government agencies are not the only people who might want to get certs in the name of a 3rd party. Crime syndicates attacking the latest race-to-the-bottom CA to get "e<some unicode glyph like x>ample.com" certs are a real issue, and DANE can handle these just fine.

Another way to look at it is that governments are the largest, most established crime syndicates, with the most rules governing their use of violence (I won't say they're the "least violent"); so again, the question is "do you want to be vulnerable to SOME crime syndicates or to ALL crime syndicates", the answer is clearly the former :).

There are arguments that DANE moves the trust problem from CAs to registrars and registries. I must admit, I don't understand the threat model here - it's asserted that registrars are cheap&cheerful (true) but they only handle public key material, and don't run the DNS; the registry is a more fruitful target, but validation of the public key material they publish for you is trivial (whereas proving that a CA somewhere hasn't signed a cert for your domain is not).

This is the sort of thing OCSP and CRLs are for, though, right?

In short, I think it's a significant net win, and as a side benefit offers greatly reduced key management burden. The ability to publish and revoke TLSA records at significantly lower cost than X.509 cert issuance, and without need to interact with a 3rd party, would be valuable even without the above. It could in theory help decouple TLS from X.509 - useful if you want to move to PGP, for example.

However, some people don't agree. Moxie Marlinspike discusses the general issues and makes an argument against DANE - see:

http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/

...and the video of the talk here:

http://www.youtube.com/watch?v=Z7Wl2FW2TcA

Interesting reading. Thanks for presenting the opposing view as well :).

He essentially suggests a trusted notary system - a working implementation of which you can see here:

http://convergence.io/

I agree that this approach is promising. I am not super-confident that it will take off - end-users literally DO NOT CARE about these issues until it's too late - but if someone (Chrome, Firefox) starts bundling notary functionality and prompting users to trust one or more of a (randomly shuffled) set of notaries on startup, it might... However, I'm not sure how likely that is - see:

https://www.imperialviolet.org/2011/09/07/convergence.html

[Note Adam Langley is "Google TLS person"]

For an alternative take on the problem, see:

http://www.certificate-transparency.org/

People interested in reading a pro-DNSSEC PoV should look here (warning - sequence of posts):

http://dankaminsky.com/2010/12/13/dnssec-ch1/

...and here:

http://www.slideshare.net/dakami/black-opspki-2

So - not as short as I'd like, but as short as I could make it. I hope that makes my position clear.

Yes, tremendously enlightening. And I thought I already understood these issues fairly well!

Finally a note on why I was reluctant to respond...

In my experience, "discussions" on TLS, X.509, DNS and DNSSEC can become very emotive, very quickly. There are people who care very, very deeply about the minutae of these issues because they directly impact the politics of privacy and symmetry of access to the internet.

I understand. But that's out there on The Internet, and not here on the eminently civil and thoughtful Twisted mailing list, where we can count on the discourse to be at a higher level :-). As you can see, no fallout has occurred!

To be honest, I lack the mental drive to engage in those discussions over the internet. Face to face might be another matter, but I have better things to do with my time than argue with strangers.

So - if anyone is sitting there bouncing up and down in their seat excited about how wrong I am - forgive me if I don't reply, I'm just not as excited about it. Look me up in real life sometime and we'll chat about it over beer!

Cheers, Phil

Thanks for taking the time to write all this up. -glyph

On 07/10/13 12:35, Tobias Oberstein wrote:

DNSSEC seems to follow a centralized/hierachical trust model. Won't help. The NSA will (does?) own those.

The default trust model is to have parent sign the child. Other models are not only possible, they're deployed. Google "DLV" and "trust anchor". As to whether "the NSA" has the root keys; given recent revelations I rule nothing out. But if this is a concern, I would urge you to investigate and get involved in the root key generation and rollover procedures - there is a rollover coming soon, and more eyes make subversion less likely.

That could be a good start: it would take a community effort to scrutinize, security review and robustify for production.

The monoculture of OpenSSL is no good IMHO.

I agree, but there are other options - gnutls, NSS - which have received this scrutiny, if you want to move away from OpenSSL.