TLS defines alert number 10 to be "unexpected message" (RFC2246, section 7.2 and 7.2.2). It indicates a protocol error; as the RFC says, "this alert should never be observed in communication between proper implementations." Which side is sending the alert, the proxy or the peer?
The way you described your original concept, it sounded like you were making the proxy be the endpoint of the TLS connections. If this is the way it is done, it obligates the proxy to encrypt/decrypt both of the connections for the entire lifetime of those connections. On decrypted-read from one, perform an encrypted-write to the other. It is NOT okay to simply use an OS-level read() and write() to do this! It is also NOT okay to simply use select() to figure out what must be done! (it can help, but it's not the be-all and end-all.) The proxy must handle each file descriptor (and its associated SSL session) separately. If select() indicates that there's data to read, the function to be called is SSL_read(). This can return -1 and the error state SSL_ERROR_WANT_WRITE, and if it does, you need to call SSL_read() again with the same parameters. When you go to write that data, use SSL_write(). This can return -1 and the error state SSL_ERROR_WANT_READ, and if it does, call SSL_write() again with the same parameters. OpenSSL will handle the underlying read() and write() calls for you, but it must be allowed to do so. Note that you can bypass this need to retry yourself if you use SSL_set_mode (or if you're using the SSL_CTX structures, SSL_CTX_set_mode) with SSL_MODE_AUTO_RETRY. If the proxy is the endpoint of all TLS sessions, then what happens on one session should not affect the other session that it's paired with (since the proxy's peers aren't talking directly with each other, they don't need to know about each other's implementations). And as for the reason you can't simply use read() and write() directly: the session keys will be different, and the rolling HMAC key will be different. This will make the other endpoint give up with a "decryption_failed" or "bad_record_mac" alert. (I still can't figure out why you'd be seeing an unexpected_message alert.) -Kyle H On Fri, Oct 31, 2008 at 4:04 AM, Weber Antonio <[EMAIL PROTECTED]> wrote: > Hi, > > >> Yes, the code is prone to deadlock. The code implements the "I will not >> start doing X until I finish doing Y" logic. This is known to cause >> deadlocks in proxies, as one end or the other of the connection proxied >> inevitably has an "I will not start doing Y until I finish doing X" logic. >> >> You thus wind up with a proxy that could make forward progress in one >> direction but refuses to because it cannot make forward progress in the >> other direction. > > please tell me where the deadlock is. > As far as I know a deadlock arise when one process locks a resource an other > process requests and vice versa. > Perhaps I misinterpret the SSL_pending > > All I do is call select which tells me if I can read on the > sockets/filehandles. > If I can read from one or both endpoints without blocking I read the > data and send it to the other endpoint. Write should never block on > sockets I think? > >> But that's not your problem. You're problem is that you are horribly >> abusing SSL_pending. SSL data may be neither in the socket buffer nor >> pending, and you ignore it. (For example, the SSL connection may have, in >> its buffer, an entire SSL protocol block. No data is pending, since the >> first byte of the block has not been analyzed yet, and no data is waiting >> on the socket.) > > The question is how will I find out that there is data I can read. > Calling select is not sufficent? > >> In general terms, a general-purpose proxy can never say "I could do X, but >> I won't do it *now*". You break this rule in two ways. One with >> SSL_pending (which checks for one type of forward progress while ignoring >> another) and by blocking in one direction even when you could make >> progress in the other. >> >> DS >> > > Greetings, > Antonio > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
