-
Bug
-
Resolution: Fixed
-
P3
-
9, 10
-
b18
-
Verified
RFC 5246 [1] says the following about empty TLS plaintexts (section 6.2.1):
...
Implementations MUST NOT send zero-length fragments of Handshake, Alert, or ChangeCipherSpec content types. Zero-length fragments of Application data MAY be sent as they are potentially useful as a traffic analysis countermeasure.
...
If a client doesn't follow this requirement, JSSE server is going to wait for a not-empty TLS plaintext while handshaking. If the client keeps sending empty TLS plaintexts, then JSSE server is going to wait forever. This doesn't look dangerous, but this behavior may waste some server resources. Please see attached test to reproduce the issue.
Since the spec says that client must not send an empty TLS plaintext when handshaking, JSSE server may probably reject an empty TLS plaintext, and close the connection.
[1] https://tools.ietf.org/html/rfc5246#section-6.1
...
Implementations MUST NOT send zero-length fragments of Handshake, Alert, or ChangeCipherSpec content types. Zero-length fragments of Application data MAY be sent as they are potentially useful as a traffic analysis countermeasure.
...
If a client doesn't follow this requirement, JSSE server is going to wait for a not-empty TLS plaintext while handshaking. If the client keeps sending empty TLS plaintexts, then JSSE server is going to wait forever. This doesn't look dangerous, but this behavior may waste some server resources. Please see attached test to reproduce the issue.
Since the spec says that client must not send an empty TLS plaintext when handshaking, JSSE server may probably reject an empty TLS plaintext, and close the connection.
[1] https://tools.ietf.org/html/rfc5246#section-6.1