Summary: | SecureNioChannel fails with "IllegalArgumentException: You can only read using the application read buffer provided by the handler." | ||
---|---|---|---|
Product: | Tomcat 9 | Reporter: | Maksym <mfedoryshyn> |
Component: | Connectors | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 9.0.12 | ||
Target Milestone: | ----- | ||
Hardware: | PC | ||
OS: | Mac OS X 10.1 |
Description
Maksym
2018-10-02 08:57:30 UTC
I couldn't figure out why it was such a drama to not use the container buffer for NIO SSL (except: no resize ...), so I didn't put it in NIO2, that's why it works. The code path clearly uses the application provided buffer in SecureNioChannel in the situation you describe where there are no bytes left. Either way, I would simply remove the check. Comments ? I'll do some svn archaeology to see if I can find out why that check was added in the first place and if that reason is still valid. Either way the check is pointless, removing it means it will cause an IOE later only if a resize is (somehow) needed. The scenario is handled well in the code. I am currently looking at the openjdk sources to see what circumstances, if any, a resize would be required. I agree the check is pointless for the reasons outlined in comment #3. Having looked at the openjdk source I think there is a lot of scope to clean this up. The TLS spec specifies a maximum of 2^14. Java defaults to this or, if jsse.SSLEngine.acceptLargeFragments is set, defaults to 2^15 to allow for non-compliant TLS stacks. After that any renegotiation of the app buffer size is only ever going to be downwards - not upwards - for any given session. The same goes for the packet buffer. I think we can remove the whole resize concept. We added it thinking the language in the Javadoc meant it could be resized upwards but my understanding of the code I have read is that it will only ever go downwards. Fixed in: - trunk for 9.0.13 onwards - 8.5.x for 8.5.35 onwards - 7.0.x for 7.0.92 onwards I'll look into what, if any, further clean-up is possible separately. Looks like I missed something when looking at the OpenJDK code. From the Oracle JSSE docs: <quote> Note: The SSL/TLS protocols specify that implementations are to produce packets containing at most 16 kilobytes (KB) of plain text. However, some implementations violate the specification and generate large records up to 32 KB. If the SSLEngine.unwrap() code detects large inbound packets, then the buffer sizes returned by SSLSession will be updated dynamically. Applications should always check the BUFFER_OVERFLOW and BUFFER_UNDERFLOW statuses and enlarge the corresponding buffers if necessary. SunJSSE will always send standard compliant 16 KB records and allow incoming 32 KB records. For a workaround, see the System property jsse.SSLEngine.acceptLargeFragments in Customizing JSSE. </quote> If we removed the resizing then any spec non-complaint clients are going to fail until Tomcat is restarted with the above system property set. On balance, I think it is best to leave things as they are. +1 to leave it as is. Thank you for fixing it! Does it make sense to backport this fix to tomcat 8.0.x as well (especially taking into account that it was fixed in 7.0.x)? The Tomcat 8.0 branch is EOL. (In reply to Mark Thomas from comment #6) > Fixed in: > - trunk for 9.0.13 onwards > - 8.5.x for 8.5.35 onwards > - 7.0.x for 7.0.92 onwards > > I'll look into what, if any, further clean-up is possible separately. When 9.0.13 is planned for release? |