FULL PRODUCT VERSION :
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.3.9600]

A DESCRIPTION OF THE PROBLEM :
The problem occurs when a SSL server responds to a Java client request to establish a SSL connection with a degradation to TLS V1.0. This will sometimes result in a one byte displacement of the transmitted plaint text data originally provided by the client. More precisely spoken, the first byte of the client data stream gets lost before it is transported via SSL.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
- create a SSL echo Java server
- create a SSL echo Java client
- force server to degrade to TLS V1.0 using sslServerSocket.setEnabledProtocols(new String[] { "TLSv1" });
- send buffers from client to server

The behaviour seems to be somehow dependent on the data length. Using different buffers in my test environment leads to different results. Sometimes both of my test buffers are transmitted correctly, sometimes both faulty and some times only the second is faulty.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The following is an excerpt of the SSL debug trace and my trace when using TLSV1.2

00 ### SSLEchoClient.main() ###
01 data
02 data SSLEchoClient.main: test buffer 2 [31 bytes]
03 data 0000 0000001F 10000040 00130002 EE010001 * .......@........ *
04 data 0010 0DEE0200 0110EE03 0005E3D6 D1C5E2 * ............... *
05 Padded plaintext before ENCRYPTION: len = 80
06 0000: 3A A0 3A A4 96 70 A6 C5 E0 CE E6 07 19 20 DF 71 :.:..p....... .q
07 0010: 00 00 00 1F 10 00 00 40 00 13 00 02 EE 01 00 01 .......@........
08 0020: 0D EE 02 00 01 10 EE 03 00 05 E3 D6 D1 C5 E2 FF ................
09 0030: FE FD FC C9 30 15 80 70 55 A9 B3 60 E9 AC C2 B0 ....0..pU..`....
10 0040: FC 12 C5 13 6A 97 DC 08 08 08 08 08 08 08 08 08 ....j...........
11 main, WRITE: TLSv1.2 Application Data, length = 80
12 [Raw write]: length = 85

The data buffer shown in lines 03 and 04 is correctly sent by the client as traced in lines 07 and 08.
ACTUAL -
The following is an excerpt of the SSL debug tracd and my trace when using TLSV1.0

00 ### SSLEchoClient.main() ###
01 data
02 data SSLEchoClient.main: test buffer 2 [31 bytes]
03 data 0000 0000001F 10000040 00130002 EE010001 * .......@........ *
04 data 0010 0DEE0200 0110EE03 0005E3D6 D1C5E2 * ............... *
05 Padded plaintext before ENCRYPTION: len = 32
06 0000: 00 60 7D B3 2E B2 FA B7 EC 34 1A C8 E7 17 7A BE .`.......4....z.
07 0010: 1E CC A5 1B 28 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A ....(...........
08 main, WRITE: TLSv1 Application Data, length = 32
09 [Raw write]: length = 37
10 0000: 17 03 01 00 20 44 43 EB 50 B3 50 D8 F0 00 57 62 .... DC.P.P...Wb
11 0010: 62 7C 70 AE 6F FB 71 F4 55 F5 E3 1C F6 BF 06 58 b.p.o.q.U......X
12 0020: FB 1E 13 CD 93 .....
13 Padded plaintext before ENCRYPTION: len = 64
14 0000: 00 00 1F 10 00 00 40 00 13 00 02 EE 01 00 01 0D ......@.........
15 0010: EE 02 00 01 10 EE 03 00 05 E3 D6 D1 C5 E2 FF FE ................
16 0020: FD FC FB 08 72 2F C4 C5 F3 DC EA 7E 3B 8B F4 4F ....r/......;..O
17 0030: 91 68 14 74 B2 5F 09 09 09 09 09 09 09 09 09 09 .h.t._..........
18 main, WRITE: TLSv1 Application Data, length = 64

The data buffer shown in lines 03 and 04 is incorrectly sent by the client as traced in lines 14 and 15. The first byte (0x00) is missing.


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
I've provided a zip-file containing 2 source files at the follwing link for download:

http://www.xps-software.de/download/SSLEchoServerTest.zip

In this example only the second buffer will be sent incorrectly.
---------- END SOURCE ----------