Java SSL Streaming - splitted applicationdata

Question

I try to send a byte[] () over a established SSL Connection (handshake etc is done).

The result: The byte[] is spitted into two packets (see debug below):

• First packet: just the first byte of the application data (**01**) .
• Second packet: the rest (fe db 01 00 ...) 650 Bytes

Is there a way to commit all application data bytes in one packet?

Stream to send 651 Bytes:

**01** fe db 01 00 00 02 83 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 31 2e 30 22 20 65 6e 63 6f 64 69 6e 67 3d 22 75 73 2d 61 73 63 69 69 22 20 73 74 61 6e 64 61 6c 6f 6e 65 3d 22 6e 6f 22 3f 3e …

javax.net.debug output

Padded plaintext before ENCRYPTION:  len = 32
0000: **01** 06 03 06 46 7F 7F AE   D4 E8 30 5D B7 DB 3C 44  ....F.....0]..<D
0010: 02 08 C9 2A A1 0A 0A 0A   0A 0A 0A 0A 0A 0A 0A 0A  ...*............
1, WRITE: TLSv1 Application Data, length = 32
[Raw write]: length = 37
0000: 17 03 01 00 20 B3 4E EE   CE 5B 69 EC A5 4A 80 7F  .... .N..[i..J..
0010: D6 03 35 AF 6A 7B 85 17   B7 46 A2 31 B2 EF 7E D0  ..5.j....F.1....
0020: EA 1B 67 7E ED                                     ..g..
Padded plaintext before ENCRYPTION:  len = 672
0000: FE DB 01 00 00 02 83 3C   3F 78 6D 6C 20 76 65 72  .......<?xml ver
0010: 73 69 6F 6E 3D 22 31 2E   30 22 20 65 6E 63 6F 64  sion="1.0" encod
0020: 69 6E 67 3D 22 75 73 2D   61 73 63 69 69 22 20 73  ing="us-ascii" s
0030: 74 61 6E 64 61 6C 6F 6E   65 3D 22 6E 6F 22 3F 3E  tandalone="no"?>
[…]

Answer 1

Sun's impl comments:

By default, we counter chosen plaintext issues on CBC mode ciphersuites in SSLv3/TLS1.0 by sending one byte of application data in the first record of every payload, and the rest in subsequent record(s). Note that the issues have been solved in TLS 1.1 or later.

Experiment with SSLEngine.wrap( largePlainText ) shows that it produces 2 SSL records, the 1st record contains 1 byte of plain text, the 2nd record contains 15846 bytes of plain text.

The receiver API probably handle record-by-record, so it'll return 1 byte for the 1st read.

We can also observe this behavior in other SSL impls, e.g. HTTPS requests from web browsers.

OpenSSL inserts empty records against the attack. If the receiver is Java SSL socket, the input stream cannot return 0 bytes for read(), so the record is skipped. Other receivers may not be prepared for a 0-length record and may break.