> On Wed, Sep 26, 2007 at 11:03:21AM +0200, Steffen DETTMER wrote: > > > > > So your point is that some property from the original > > > > certificate (lets say some hash or so) could be included in > > > > the extra authentication to detect a MITM (or whatever faked) > > > > certificate? In that case, SSL would be used basically for > > > > encryption only, right? > > > > > > Exactly.
> Actually not the certificate, it has to be a nonce securely derived from > the current SSL handshake, the certificate alone does not qualify. This > nonce then has to be used securely in a second authentication step that > must work if both sides have the same nonce, and fail otherwise. I am not enough of an expert to comment for sure on this, but it seems that there would be no harm in using the certificate for this purpose. A MITM cannot create an SSL session that uses the same certificate as the real server because that would mean the MITM would have to know the same private key the real server is using. In any event, implementations I know of use a hash of the two finished messages. These implementations were professionally vetted. > This is certainly possible, but the vast majority of users (i.e. > programmers) this is IMHO a bad idea. I am not alone in this view. > Use TLS with a properly integrated cipher-suite and a suitable key > management/trust model. So what do you do if the conventional trust model is not the security model you need to implement? Throw out TLS when it does everything you need except detect a MITM? That seems much riskier IMO. > > Ahh, ok. I assumed SSL and TLS would specify how to authenticate > > and how to derive keys (to be interoperable), but also Victor > > explained my that there are more flexible possibilites such as > > defining new cipher suites (before, I assumed the standard would > > require a lowest common dominator such as > > TLS_RSA_WITH_3DES_EDE_CBC_SHA and so on to get all > > implementations interoperable). > Programmers should not define new cipher-suites, protocol designers > should design and review them, then standards committees adopt them and > toolkit vendors (e.g. OpenSSL) implement them. Definitely. > David's proposal very likely works for him, but IMHO is bad advice, > because the sophistication required to execute it correctly is too high. Do you know any other good way to get MITM detection other than a certificate issued by a trusted CA? For some applications, that's just not what you want. > I would not use a product that rolled its own MITM-immune authentication > layer post-SSL. With cryptographic products, follow the herd and don't > stray. If you can't trust a TLS/SSL connection to exchange authentication information, then you can't trust a secure web page with a password. That's obviously not right. In practice, what you get if you follow this policy is no MITM detection at all. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
