Recent Features
| |||||||||||||
TLS renegotiation vulnerabilityTLS renegotiation vulnerabilityPosted Nov 22, 2009 1:29 UTC (Sun) by Cyberax (✭ supporter ✭, #52523)In reply to: TLS renegotiation vulnerability by njs Parent article: TLS renegotiation vulnerability
>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...
(Log in to post comments)
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.
|
|||||||||||||