This is a discussion on Re: SSL alert number 10 after quite exactly 1MB transfered - Openssl ; 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, ...
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
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.)
On Fri, Oct 31, 2008 at 4:04 AM, Weber Antonio
>> 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.
OpenSSL Project http://www.openssl.org
User Support Mailing List email@example.com
Automated List Manager firstname.lastname@example.org