I'm going to punt this and suggest first and foremost that at least part of this is a MatrixSSL issue (it's not handling the protocol correctly, so it's extremely possible and even likely that it's treating other aspects of SSLv3 like they're TLSv1+). You should contact PeerSec and inform them that their SSL implementation is causing OpenSSL to throw an "unexpected message" alert, which per the spec should never be seen between conforming implementations.
This doesn't mean that OpenSSL is entirely off the hook, either, because it should report on what exactly the unexpected message was, if it doesn't already (it could already be in the error stack somewhere). I'd also suggest that you take what David says to heart. What you need to do is have a queue for each endpoint that you read into, and then write from, as separate events (for each endpoint, first see if you have anything you need to write, attempt to write it, then attempt to read, then go to the next endpoint and write/read from it, and so on). Decouple the acts of reading from an endpoint and writing to its paired endpoint. This will allow your proxy to "make forward progress" at all times, without relying on writing to its paired endpoint to determine if you do or not. -Kyle H On Sat, Nov 1, 2008 at 1:33 AM, Antonio Weber <[EMAIL PROTECTED]> wrote: > Hi, > > up to now the error message is still the same - thats the last lines of > repeater before the repeat thread crashes > > Server: bytesReceived: 1024 / bytesSent: 1024 / sumS: 1022335 > Server: bytesReceived: 1024 / bytesSent: 1024 / sumS: 1023359 > Server: bytesReceived: 1024 / bytesSent: 1024 / sumS: 1024383 > Server: bytesReceived: 1024 / bytesSent: 1024 / sumS: 1025407 > Server: bytesReceived: 1024 / bytesSent: 1024 / sumS: 1026431 > Server: bytesReceived: 903 / bytesSent: 903 / sumS: 1027334 > 4409:error:140943F2:SSL routines:SSL3_READ_BYTES:sslv3 alert unexpected > message:s3_pkt.c:1053:SSL alert number 10 > > Thats the EXACT error message the repeat thread prints. (It has not > changed since my first mail) > > When sniffing the traffic with wireshark on the clientside I can see, > that the client is sending 'SSLv3: Encrypted Alert / Alert 21 (0x15)' to > the repeater. > If wireshark misinterpret the message or whatever - thats the last > message which is sent from the client to the repeater. > I do not know why I get SSL alert number 10 though I sniff alert 21 > with wireshark but what I describe is consistent and true. > If you want to see the wireshark dump or something else I can give it to > you. > Perhaps the client implementation (matrixssl) sends the TLS message 21 > in an SSLv3 packet. Because in the standard there is no error 21 defined > in SSLv3 openssl makes an alert number 10 - unexpected_message out of > it? > > Let me describe why I started using SSL_pending at all: > The server connects to the repeater first. After connection I use > SSL_set_fd() / SSL_accept to set up the ssl. Then the server sends the > char 'S' and a id. After that the 'SSL' - pointer to the server > connection > hangs in a bookkeeping tree (id points to a struct which contains the > pointer to the SSL - struct and some other information). But after > sending the ID, the server sends another 12 bytes of data which should > be read in the repeat thread at all. > When the client connects he send an 'C' (for Client) and the an Id (the > id he want to be connected with). In the tree I search for this id, get > the SSL pointer to the server and start the repat thread with both > handles. Without the SSL_pending() select blocked forever. First I had > no idea why till I found SSL_pending function which returned 12 when I > called it at repeat startup. My conclusion was that ssl lib already read > the data which came from the server (there was enough time till the > client connected) and wrote it to a buffer in the lib => no more to read > on the socket itself and select blocked forearch because the client > waits for these 12 bytes. > How shall I handle this? Use a goto to jump directly in the ssl_read > from the server? > > Thanks a lot for your time - I hope I fixed it soon :) > > Greetings, > Antonio > > >> Okay. SSLv3 is different from TLSv1.0. And you really, really, >> REALLY need to give the correct error. Your original message said it >> was alert number 10, not alert 21. >> >> Alert 21 is not specified in SSLv3 (see >> http://www.freesoft.org/CIE/Topics/ssl-draft/3-SPEC.HTM for the alert >> definitions, section 7.4 and 7.4.2). It is specified in TLSv1 (RFC >> 2246), though, and is decryption_failed. See >> ftp://ftp.rfc-editor.org/in-notes/rfc2246.txt for the specification. >> >> If there is data available for SSL_read() to read on the socket, >> select() will tell you. You should not use SSL_pending for the task, >> for the reason that David mentioned. You should realize that it's >> possible for SSL_read() to return 0 even in the event that there is >> data available on the socket, and it's also possible for it to return >> -1 with SSL_ERROR_WANT_WRITE -- a partial packet might have been >> delivered, or it might just be a renegotiation with no user data >> available. Either way, you should structure your code to call >> SSL_read() on any descriptor that select() says has pending data, and >> only then if you actually have any application data in there should >> you try to copy anything to the other side of the proxied pair. >> Remove the call to SSL_pending() -- just let the library deal with its >> internal bookkeeping, and make your code a little more naïve. >> >> Remember, SSL_read() returns the number of bytes it read from the >> stream. If it's 0, then there's no user data, even if it did need to >> do a renegotiation. In that case, just continue; your select() loop >> without trying to complete copying of a 0-length buffer. And it can >> return -1/SSL_ERROR_WANT_* at any time (if the auto-retry option isn't >> set). >> >> -Kyle H > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] >
