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

The assumption you're making about reading the byte[] exactly as you write them on the other end is a classic TCP mistake. It's not actually specific to SSL/TLS, but could also happen with a TCP connection.

There is no guarantee in TCP (and in SSL/TLS) that the reader's buffer will be filled with the exact same packet length as the packets in the writer's buffer. All TCP guarantees is in-order delivery, so you'll eventually get all your data, but you have to treat it as a stream.

This is why protocols that use TCP rely on indicators and delimiters to tell the other end when to stop reading certain messages.

For example, HTTP 1.1 uses a blank line to indicate when the headers end, and it uses the Content-Length header to tell the recipient what entity length to expect (or chunked transfer encoding). SMTP also uses line returns and . at the end of a message.

If you're designing your own protocol, you need to define a way for the recipient to know when what you define as meaningful units of data are delimited. When you read the data, read such indicators, and fill in your read buffer until you get the amount of bytes you expect or until you find the delimiter that you've defined.

Answer 2

I had the same problem until I saw this page: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7157903

So, I run the JVM with -Djsse.enableCBCProtection=false parameter and now the data is not splitted.

Best regards

Answer 3

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.