Re: how to defeat MITM using plain DH, Re: anonymous DH MITM
[Using multiple channels on the assumption that the MITM can't always get all of them.] This is starting to sound like some very old work - to which I don't have a reference - on what was called the wiretap channel. Basic idea: Alice and Bob wish to talk; Carol can listen in to everything, but her tap isn't perfect, so she gets a BER that's slightly higher. Alice and Bob can then choose a code (in the information-theory sense, not the crypto sense) that is fine-tuned to exactly match their BER - and also has the property that if you have one more bit error than the code supports, you can't decode at all. They get through, Carol gets nothing. The same idea has been revived in creating CD's that work in audio players but not PC's (which hvae CD drives that typically are not willing to tolerate as high an error rate.) -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Protocol implementation errors
| This is the second significant problem I have seen in applications that use | ASN.1 data formats. (The first was in a widely deployed implementation of | SNMP.) Given that good, security conscience programmers have difficultly | getting ASN.1 parsing right, we should favor protocols that use easier to | parse data formats. | | I think this leaves us with SSH. Are there others? | | I would say the exact opposite: ASN.1 data, because of its TLV encoding, is | self-describing (c.f. RPC with XDR), which means that it can be submitted to a | static checker that will guarantee that the ASN.1 is well-formed. In other | words it's possible to employ a simple firewall for ASN.1 that isn't possible | for many other formats (PGP, SSL, ssh, etc etc). This is exactly what | cryptlib does, I'd be extremely surprised if anything could get past that. | Conversely, of all the PDU-parsing code I've written, the stuff that I worry | about most is that which handles the ad-hoc (a byte here, a unit32 there, a | string there, ...) formats of PGP, SSH, and SSL. We've already seen half the | SSH implementations in existence taken out by the SSH malformed-packet | vulnerabilities, I can trivially crash programs like pgpdump (my standard PGP | analysis tool) with malformed PGP packets (I've also crashed quite a number of | SSH clients with malformed packets while fiddling with my SSH server code), | and I'm just waiting for someone to do the same thing with SSL packets. In | terms of safe PDU formats, ASN.1 is the best one to work with in terms of | spotting problems. I think there's a bit more to it. Properly implementing demarshalling code - which is what we are really talking about here - is an art. It requires an obsessive devotion to detailed checking of *everything*. It also requires a level and style of testing that few people want to deal with. Both of these are helped by a well-specified low-level syntax. TLV encoding lets you cross-check all sorts of stuff automatically, once, in low-level calls. Ad hoc protocols scatter the validation all over the place - and some of it will inevitably be overlooked. A couple of years back, the place I work decided to implement its own SNMP library. (SNMP is defined in ASN.1) We'd been using the same free library done at, I think, UC San Diego many years before, and were unhappy with many aspects of it. The guy we had do it had the right approach. Not only did he structure the code to carefully track and test all suspect data, but he also wrote a test suite that checked: - Many valid inputs. Most people stop here: It gets the right results on valid data, who cares about the rest. - Many expectable forms of invalid data. A few people will write a few of these tests. Usually, they write test cases that match the error paths they thought to include in their code. Fine, but not nearly enough. - Many randomly-generated tests. The trick here is to shape the randomness: Most completely random bit strings will be rejected at very low levels in the code. What you want are strings that look valid enough to pass through multiple layers of testing but contain random junk - still with some bias, e.g., 1 too high or too low is a test you want to bias toward. Hardly anyone does this. The proof of the pudding came a couple of years later, when a group a OUSPG (Oulu University Secdure Computing Group) came up with a test that ripped through just about everyone's SNMP suites, leading to a CERT advisory and a grand panic. Our stuff passed with no problems, and in fact when we looked at OUSPG's test cases, we found that we had almost certainly run them all in some form or another already, since they were either in our fixed test list or were covered by the randomized testing. OUSPG's efforts were actually directed toward something more on point to this discussion, however: Their interest is in protocol test generation, and their test cases were generated automatically from the SNMP definitions. This kind of thing is only possible when you have a formal, machine-readable definition of your protocol. Using ASN.1 forces you to have that. (Obviously, you can do that without ASN.1, but all too often, the only definition of the protocol is the code. In that case, the only alternative is manual test generation - but it can be so hard to do that it just doesn't get done.) BTW, the OUSPG saga is another demonstration of the danger of a monoculture. There are, it turns out, vey few independent implementations of SNMP around. Just about everyone buys SNMP support from SNMP Research, which I believe sells a commercialized version of the old UCSD code. Find a bug in that, and you've found a bug in just about every router and switch on the planet.
Re: anonymous DH MITM
On Sat, 4 Oct 2003, Benja Fallenstein wrote: Does it work? Assume A() is Alice's series, B() is Bob's, MA() is the one Mitch uses with Alice, MB() the one Mitch uses with Bob. - Mitch sends first half of cyphertext of MA(1000) (to Alice) - Alice sends first half of cyphertext of her move + A(1000) (to Mitch) - Mitch sends second half - Alice sends second half Mitch can now decrypt Alice's move. - Bob sends first half of cyphertext of B(1000) (to Mitch) - Mitch sends first half of cyphertext of Alice's move + MB(1000) (to Bob) - Bob sends second half. - Mitch sends second half. Bob decides on his move. - Bob sends first half of ciphertext of his move + B(999) (to Mitch) - Mitch sends first half of ciphertext of MB(999) (to Bob) - Bob sends second half. - Mitch sends second half. Mitch can now decrypt Bob's move... Am I missing something? Yes, although I hadn't immediately realized it would be necessary: Timing information. If you require 30-45 seconds between packets, Mitch's game dies a rapid death. T:0 - Mitch sends first half of cyphertext of MA(1000) (to Alice) T:30 - Alice sends first half of cyphertext of her move + A(1000) (to Mitch) T:60 - Mitch sends second half T:90 - Alice sends second half Mitch can now decrypt Alice's move. T:60 - Bob sends first half of cyphertext of B(1000) (to Mitch) T:90 - Mitch sends first half of cyphertext of Alice's move + MB(1000) (to Bob) T:120 - Bob sends second half. T:135 - Alice times out waiting for Bob's response because it's 45 seconds since her last packet. Mitch must commit to a move ignorant of Bob's move by now, if he is to continue the game. T:150 - Mitch sends second half of Alice's move to Mitch Bob decides on his move. You could fiddle the intervals, within limits, or allow the players an I need more time to think move, but if they're not allowed to use it more than one time in three, then mitch isn't going to be able to make more than two moves. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Monoculture
On Sun, Oct 05, 2003 at 03:04:00PM +0100, Ben Laurie wrote: Thor Lancelot Simon wrote: On Sat, Oct 04, 2003 at 02:09:10PM +0100, Ben Laurie wrote: Thor Lancelot Simon wrote: these operations. For example, there is no simple way to do the most common certificate validation operation: take a certificate and an optional chain, and check that the certificate is signed by an accepted root CA, or that each certificate in the chain has the signing property and that the chain reaches that CA -- which would be okay if OpenSSL did the validation for you automatically, but it doesn't, really. Err, yes it does, but its not very well documented. No. You can't do it in one step, and you have to use functions that are marked in OpenSSL's header files as not being part of the official API. mod_ssl has a convenience function that's confusingly named just like the OpenSSL library functions that deals with this -- of course, it should be part of OpenSSL itself, but at least as of 0.9.6 it was not. Would you care to be more explicit? I have to apologize -- I was not entirely correct in my initial statement, but without access to the source tree I did most of my OpenSSL work in (it belongs to a former employer) it took me a while to retrace my steps and realize I was not quite right. On the client side, though the documentation's poor, you're correct: there _is_ a way to validate a certificate and chain you've received from the peer in one step. (I note that there is now reference in the header files to some AUTOCHAIN stuff that I don't recall from earlier versions of OpenSSL, but that ssl_verify_cert_chain is *still* not part of the public API; it's in ssl_locl.h). On the server side (or, indeed, on the client side, if the client side needs to follow a chain to reach a trusted CA, and thus needs to load chain certificates) there's no API for loading a cert and its entire chain in one shot, and indeed to do so AFAICT you must use functions that are not part of the public API. See SSL_CTX_use_certificate_chain() in the mod_ssl sources (which appears much simpler in mod_ssl 2.8 than what I remember working with -- perhaps the OpenSSL API *has* improved!) and SSL_use_certificate_file, SSL_CTX_use_certificate_file, and SSL_CTX_use_certificate_chain_file in the OpenSSL sources. And then note that *all* of the example code gets this stuff wrong -- if it even bothers to do server certificate validation at all. I can't lose my impression that some of the chain-handling functions moved from ssl_locl.h to ssl.h between 0.9.6 and 0.9.7 but I don't have a 0.9.6 tree handy nor the time to sift through it. Sigh. I wish I had some of my code from the last time I tackled this issue with OpenSSL at hand, but unfortunately I don't own it, so I do not. The complexity and instability of the API for this stuff, and the fact that we're both rooting around *in the OpenSSL source code* to figure out which bits of it are public and which are internal, and in which version of OpenSSL, when the operations at hand (loading and validating chains of certificates, from the cert for the peer's identity up to the cert from which trust derives) is a pretty good example, itself, of why I don't care for OpenSSL. I spent a long time working on the X.509 support in Pluto, too, and though I don't really care for it either it does have the decided advantage that it appears to be designed in the right direction: from what are the end-user's needs? instead of what is the structure of the underlying protocol or software abstraction? Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
