| |||||||||||||
TLS renegotiation vulnerabilityTLS renegotiation vulnerabilityPosted Nov 19, 2009 14:18 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)Parent article: TLS renegotiation vulnerability
Solution: let's ship all security people to Mars?
No, really. TLS/SSL standards are ridiculously complicated - you need to know about ASN.1 (and its encodings), leftovers of DAP (like braindead CNs), etc. So it's almost impossible for a single person to implement their own SSL/TLS library.
No wonder, people treat OpenSSL as a 'magic black box' which secures everything. Because it really is a black box.
What we need is a simple security protocol based on XML instead of ASN.1 with human-readable details and a manageable core standard.
(Log in to post comments)
TLS renegotiation vulnerability Posted Nov 19, 2009 16:16 UTC (Thu) by dion (subscriber, #2764) [Link]
You know, I think you're right!
However, the trouble with reimplementing a security is that security is hard, so hard that people who do go greenfield then tend to implement horrible, nasty, disastrous things like the java keystore and the java keytool.
Granted, the jks might be an unfair example as thats where SUN seems to put their dimmest interns.
I wonder if it's at all possible to get both high quality crypto code and well-designed protocols and APIs out of the same brains.
TLS renegotiation vulnerability Posted Nov 19, 2009 17:11 UTC (Thu) by nye (guest, #51576) [Link]
>I wonder if it's at all possible to get both high quality crypto code and well-designed protocols and APIs out of the same brains.
If only we could get funding for a research project to find out!
TLS renegotiation vulnerability Posted Nov 19, 2009 22:28 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Greenfield cryptoalgorithms tend to be bad, yes.
But the new Plain XML Security Protocol should use existing crypto. There's no need to reinvent the wheel.
Everything other should be mercilessly killed. I.e. ASN.1, X.509, PKCS#I'd_be_damned_if_I_remember and so on.
I think it can be done. Sometimes I even think to start writing it...
Why not Posted Nov 20, 2009 7:35 UTC (Fri) by man_ls (subscriber, #15091) [Link] It should be fun. Unfortunately the inertia of legacy implementations is often so heavy that many new efforts are not even considered. The case that always comes to my mind is the sad story of the D programming language. It looks quite interesting, but it has failed to gain wide support. Meanwhile the namespace was miserably trampled by Sun engineers with the language used in DTrace (I guess they didn't know about the former, or the temptation to use "D" was too irresistible).
TLS renegotiation vulnerability Posted Nov 20, 2009 3:28 UTC (Fri) by cras (guest, #7000) [Link]
I think a big problem with OpenSSL being a magic box is the lack of documentation, and APIs that
are quite horrible if you want to do something a bit differently than everyone else. Usually whenever I want to add a new TLS related feature I'll just try to find out existing code that does something similar (because the functions' manual pages don't exist or are almost empty). And when that fails (and it often does) I'll just have go read the OpenSSL code directly. And when I find that there doesn't exist an easy way to do what I want, I'll just go and copy&paste a large chunk of OpenSSL code to my code and modify it slightly..
I guess I should start looking at GNUTLS again, maybe things are better there..
TLS renegotiation vulnerability Posted Nov 21, 2009 18:37 UTC (Sat) by kleptog (subscriber, #1183) [Link]
I've done a little programming with GNUTLS and one things is for sure, the interface is much nicer. It was created at a time when TLS was much more standard, and certain features went it from the beginning. Like BIOs in OpenSSL are in the from the beginning. Non-blocking is supported throughout.
Certainly I found it much nicer.
TLS renegotiation vulnerability Posted Nov 20, 2009 6:35 UTC (Fri) by njs (guest, #40338) [Link]
> So it's almost impossible for a single person to implement their own SSL/TLS library.
On the one hand, you're right, TLS is ugly as sin. On the other, wtf, they're still finding bugs in *openssh* and *openssl*, which are possibly the most intensely scrutinized bits of code ever. You honestly think one random person -- one who's not even smart enough to understand ASN.1 -- is going to do better, no matter the protocol?
> What we need is a simple security protocol based on XML
Have you seen the horror that lurks in standards that mix XML and crypto? XML has many congenial aspects, but it does not mix well with the "just define a canonical bitstring dammit" world of crypto.
TLS renegotiation vulnerability Posted Nov 22, 2009 1:29 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
>On the other, wtf, they're still finding bugs in *openssh* and *openssl*, which are possibly the most intensely scrutinized bits of code ever. You honestly think one random person -- one who's not even smart enough to understand ASN.1 -- is going to do better, no matter the protocol?
For starters, why not use a garbage-collected safe language (compiled one which doesn't require a VM, like OCaml or D) for reimplementation of OpenSSH? It'd instantly decrease the number of exploitable buffer-overflow bugs nearly to zero. In fact, I'm reading OpenSSH CVEs and almost _all_ of them are caused by its usage of unsafe language.
New OpenSSL should still be implemented in C, because it's the lowest common denominator, alas.
>Have you seen the horror that lurks in standards that mix XML and crypto? XML has many congenial aspects, but it does not mix well with the "just define a canonical bitstring dammit" world of crypto.
It's actually not that complex. The relevant standards are: http://www.w3.org/TR/xml-c14n and http://www.w3.org/TR/xml-exc-c14n/ , they are nicely _short_ and can be quite easily implemented. In fact, I've implemented a subset of them in the past quite easily.
XML signature core standard is also very nice and readable: http://www.w3.org/TR/xmldsig-core/
Hmm... It's actually not that much work to build new security protocol...
TLS renegotiation vulnerability Posted Nov 22, 2009 4:49 UTC (Sun) by foom (subscriber, #14868) [Link]
> It's actually not that complex.
Are you kidding? That's *insane*ly complex, compared to just having a single standard spelling.
TLS renegotiation vulnerability Posted Nov 22, 2009 17:01 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
Well, if I had a choice between ASN.1 and insanely complex XML rules, then I'd still choose XML.
The trick in doing XML dsig is to output XML directly in a canonical format, then you can have a pretty fast implementation.
It's still slower than uber-optimized ASN.1 parsers, but personally, I don't care even if it's 10x slower.
TLS renegotiation vulnerability Posted Nov 23, 2009 0:17 UTC (Mon) by foom (subscriber, #14868) [Link]
> Well, if I had a choice between ASN.1 and insanely complex XML rules, then I'd still choose XML.
That's a bit silly. Have you ever looked at ASN.1? It's really quite trivial. So much easier than XML,
http://en.wikipedia.org/wiki/Basic_Encoding_Rules
Certificates actually use DER, which is a slightly restricted subset of BER:
TLS renegotiation vulnerability Posted Nov 23, 2009 8:26 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Unfortunately, I've worked with it. And that's why I'm quite sure: wherever ASN.1 goes, destruction and pain follows. Examples: LDAP, SNMP, SSL/TLS, Kerberos.
To be fair, XML canonicalization rules are designed for arbitrary XML. It's possible to simplify them by using a subset of XML. For example, by restricting entities, CDATA and namespace use.
In any case, less complex formats like JSON can be used instead of XML.
TLS renegotiation vulnerability Posted Nov 23, 2009 13:50 UTC (Mon) by quotemstr (subscriber, #45331) [Link] wherever ASN.1 goes, destruction and pain follows. Examples: LDAP, SNMP, SSL/TLS, Kerberos.You have an interesting definition of "destruction and pain". These protocols are used all over the place and are successful by any measure.
TLS renegotiation vulnerability Posted Nov 23, 2009 15:49 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Do you know how to make a simple request with LDAP? Can you write a simple LDAP Ping using plain sockets?
I can easily do this for HTTP/FTP/SMTP even IMAP. I don't even want to contemplate this for SSL/TLS.
That's the problem, it's impossible to create a simple client for SSL.
|
|||||||||||||