Netty SSL mode strange behavior

Question

I am trying to understand, why does Netty SSL mode work on strange way? Also, the problem is following, when any SSL client(https browser, java client using ssl, also any ssl client application) connects to Netty server I get on beginning the full message, where I can recognize correctly the protocol used, but as long the channel stays connected, any following messages have strange structure, what is not happening same way with non-ssl mode. As example on messageReceived method when the https browser connects to my server:

I have used PortUnificationServerHandler to switch protocols.. (without using nettys http handler, it is just example, because i use ssl mode for my own protocol too)

1. first message is ok, I get full header beginning with GET or POST
2. than I send response...
3. second message is only one byte long and contains "G" or "P" only.
4. third message is than the rest beginning either with ET or OST and the rest of http header and body..
5. here again follows my response...
6. fourth message is again one byte long and again contains only one byte..
7. fifth message again the rest... and on this way the game goes further..

here it is not important, which sub protocol is used, http or any else, after first message I get firstly one byte and on second message the rest of the request..

I wanted to build some art of proxy, get ssl data and send it unencoded on other listener, but when I do it directly without waiting for full data request, the target listener(http server as example) can not handle such data, if the target gets one byte as first only (even if the next message contains the rest), the channel gets immediately closed and request gets abandoned.. Ok, first though would be to do following, cache the first byte temporarily and wait for next message and than join those messages, and only than response, that works fine, but sometimes that is not correct approach, because the one byte is sometimes really the last message byte, and if i cache it and await wrongly next message, i can wait forever, because the https browser expects at this time some response and does not send any data more..

Now the question, is it possible to fix this problem with SSL? May be there are special settings having influence on this behavior? I want fully joined message at once as is and not firstly first byte and than the rest.. Can you please confirm, that with newer Netty versions you have same behaving by using PortUnificationServerHandler (but without netty http handler, try some own handler.) Is this behavior Ok so, I do not believe, it was projected so to work..

Answer 1

What you're experiencing is likely to be due to the countermeasures against the BEAST attack.

This isn't a problem. What seems to be the problem is that you're assuming that you're meant to read data in terms of messages/packets. This is not the case: TCP (and TLS/SSL) are meant to be used as streams of continuous data. You should keep reading data while data is available. Where to split incoming data where it's meaningful is guided by the application protocol. For HTTP, the indications are the blank line after the header and the Content-Length or chunked transfer encoding for the entity.

If you define your own protocol, you'll need a similar mechanism, whether you use plain HTTP or SSL/TLS. Assuming you don't need it only works by chance.

Answer 2

I had experienced this issue and found it was caused bu using JDK1.7. Moving back to JDK1.6 solved it. I did not have time to investigate further but have assumed for now that the SSLEngine implementation has changed in the JDK. I will investigate further when time permits.