On Mon, May 19, 2008 at 10:53 PM, Simon Josefsson <[EMAIL PROTECTED]> wrote: > "Rainer Gerhards" <[EMAIL PROTECTED]> writes: > [snip]
>> In essence, I am looking for something like a callback that is called >> during handshake with the remote cert and that can reply with auth >> success/failure - all while in the handshaking porcess. >> >> Does that make any sense? > > Yes, although I'm not sure it is a good idea to do it as part of the > handshake: until the handshake is over, you don't know whether there is > a man in the middle attacker present. I am (obviously;)) not a TLS expert. I thought that when I receive a certificate during the handshake, I can validly assume that it reflects the remote peer's identity. Could you enlighten me why there is a man-in-the-middle attack possible? I would like to get this right because I may need to bring it up inside the IETF discussion (and obviously I want to be correct then ;)). >I suggest completing the > handshake as normal, and then compare fingerprints. If fingerprint > comparisons fails, shut down the TLS session. Actually, this is what I am currently doing. BUT... the syslog story is even worse ;) Syslog is simplex communication and the syslog TLS internet draft in question maps this simplex nature onto a TCP stream WITHOUT acknowledgments (except for the TCP ack, of course). While this sounds quite strange, there are some good reasons for doing so (I do not elaborate, because it would end up at a veeeeery long off-topic post). Of course, there are inherent problems. One is that after the handshake completes, the sender assumes it may send syslog messages. When the server then drops the connection, some of these messages are lost, but the sender can not detect which ones exactly. This is NOT theoretical, I experience that in my lab. It was the reason I asked the initial question. If you would like to dig deeper into that problem, you can find a good description in a blog post I wrote a while ago: http://rgerhards.blogspot.com/2008/04/on-unreliability-of-plain-tcp-syslog.html The only solution to this problem is to have the fingerprint authentication carried out during the handshake procedure - so that the server does NOT need to drop the connection after the handshake (at least not for authentication reasons). > Ideally, I think the IETF draft should discuss some of these details. > It is easy to implement ssh-style leap-of-faith authentication > incorrectly. I have also posted a question on the IETF list when exactly the fingerprint authentication must happen. In my current understanding (which may be wrong), the draft actually specifies it must happen during handshake (which, as I said, would be the right thing here). I have not yet received a reply. If you are interested, you may follow the discussion here in the mailing list archive: http://www.ietf.org/mail-archive/web/syslog/current/msg01910.html Thanks again for your help. Rainer _______________________________________________ Help-gnutls mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnutls
