I’m writing a program in java that send official invoice information to the Fiscal Administration. This public service provided certificates to use in the SSL connection to the web services and to encrypt some especial data fields inside the request body message.
I’m having an EOFException error during the handshake phase after client and server have agreed to communicate using the agreed cipher suite that in this case is TLS_RSA_WITH_AES_128_CBC_SHA.
Following the SSL protocol the client perform with success a test using the new cipher and send the test data to the server so the server can also repeat the same test and confirm that it is also capable of encrypt and decrypt data. And in this point the server send the EOFException.
Here is the last part of the SSL communication log:
Send a quick confirmation to the server verifying that we know the private key corresponding to the client certificate we just sent...
* CertificateVerify
[write] MD5 and SHA1 hashes: len = 262
binary data here too large not displayed
main, WRITE: TLSv1 Handshake, length = 262
[Raw write]: length = 267
binary data here too large not displayed
*Tell the server we're changing to the newly established cipher suite. All further messages will be encrypted using the parameters we just established. *
main, WRITE: TLSv1 Change Cipher Spec, length = 1
[Raw write]: length = 6
0000: 14 03 01 00 01 01
... and finishes with success
..Finished
We send an encrypted Finished message to verify everything worked.
verify_data: { 221, 96, 47, 110, 19, 170, 244, 8, 37, 152, 160, 40 }
...
The client encrypt the test data..
[write] MD5 and SHA1 hashes: len = 16
0000: 14 00 00 0C DD 60 2F 6E 13 AA F4 08 25 98 A0 28 .....`/n....%..(
Padded plaintext before ENCRYPTION: len = 48
0000: 14 00 00 0C DD 60 2F 6E 13 AA F4 08 25 98 A0 28 .....`/n....%..(
0010: 10 7F 85 11 EC 6D 5D ED 21 70 27 F4 DC 23 C0 9B .....m].!p'..#..
0020: A7 6F C2 80 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B 0B .o..............
main, WRITE: TLSv1 Handshake, length = 48
* ...and send the test data to the server so that the server can do the same test and confirm that encrypted communication can be established (53 bytes = 48 from the test data + 5 from header) *
[Raw write]: length = 53
0000: 16 03 01 00 30 1C 17 08 0F 49 C9 6A 7A 8B 8C 48 ....0....I.jz..H
0010: BA 57 2D CB 06 46 1E 65 61 7C 5F 74 F2 08 AB 12 .W-..F.ea._t....
0020: 91 47 72 8C 8F 84 0A CB D7 29 E2 FD 84 B2 FD 9E .Gr......)......
0030: 47 DC 13 60 B4 G..`.
...and the server respond with the EOFException error
main, received EOFException: error
main, handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed
connection during handshake
%% Invalidated: [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA]
main, SEND TLSv1 ALERT: fatal, description = handshake_failure
Padded plaintext before ENCRYPTION: len = 32
0000: 02 28 BC 65 1A CA 68 87 79 84 5F 64 16 F5 28 72 .(.e..h.y._d..(r
0010: F7 8A 69 72 93 D8 09 09 09 09 09 09 09 09 09 09 ..ir............
main, WRITE: TLSv1 Alert, length = 32
[Raw write]: length = 37
0000: 15 03 01 00 20 0D 9A 35 18 B7 98 4B 7B AF 82 4E .... ..5...K...N
0010: 1A EE 7D AC 5D D5 49 05 4E 74 B9 77 E4 CD 87 61 ....].I.Nt.w...a
0020: 23 03 5C 9C 7E #...
main, called closeSocket()
main, called close()
main, called closeInternal(true)
I have no idea on what might be the cause for such a failure and how to programmatically influence the outcome of this step in the process. I’ve tried force the use of other ciphers recognized by both client and server such as SSL_RSA_WITH_RC4_128_MD5 but the error remain.
Any thoughts on how to solve this problem?
Any thoughts on how to solve this problem?
I suggest that you get in contact with the people who run that service, and get them to look at their logs to see why their server is closing the connection during SSL setup.
(Strictly speaking, the server does not "respond with [an] EOFException error". It is actually closing the TCP connection and the client-side Java libraries are throwing the exception. You are likely to get a more helpful response from the maintainers of the service if you use correct terminology.)
Related
Using this simple https server slightly modified to replace var with Java 8 compatible types, I can run it as such:
$ java8 -cp . -Djavax.net.debug=ssl,keygen javatester.SimpleHTTPSServer | grep Nonce -C 5
SESSION KEYGEN:
PreMaster Secret:
0000: A7 7C E0 10 EB E5 7C 16 CF 70 65 30 04 AE 5B BC .........pe0..[.
0010: 6F 61 52 6C FC 71 58 D9 F4 BD 10 70 69 10 62 2A oaRl.qX....pi.b*
CONNECTION KEYGEN:
Client Nonce:
0000: A3 E4 45 27 77 6C 0D 5E BD F1 4E 9D 1E 2E 10 02 ..E'wl.^..N.....
0010: 7F 6E A1 EC C2 BC 40 E3 1E 32 A9 B9 13 3B 6C B5 .n....#..2...;l.
Server Nonce:
0000: 5E B5 99 F9 02 EE C3 9E 84 30 01 32 B4 04 BA 38 ^........0.2...8
0010: B1 D9 B2 D9 6E 54 F4 4C BF DC 60 98 97 AD 8B B2 ....nT.L..`.....
Master Secret:
0000: D6 14 BF 8E FF 69 93 9C DB 58 35 AC 65 EF 5B A2 .....i...X5.e.[.
0010: 79 D7 3D 67 76 F7 CA 82 69 F9 30 34 9A C8 E7 EB y.=gv...i.04....
These values I can use to create a Wireshark-capable premaster secret log file to decode the connection. However, when I run this with jdk 11, I don't get any keygen output:
$ java11 -cp . -Djavax.net.debug=ssl,keygen javatester.SimpleHTTPSServer
Start single-threaded server at /0.0.0.0:8443
javax.net.ssl|DEBUG|01|main|2020-05-08 13:51:10.479 EDT|SSLCipher.java:437|jdk.tls.keyLimits: entry = AES/GCM/NoPadding KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472
javax.net.ssl|DEBUG|01|main|2020-05-08 13:51:24.367 EDT|SSLCipher.java:1824|KeyLimit read side: algorithm = AES/GCM/NOPADDING:KEYUPDATE
countdown value = 137438953472
javax.net.ssl|DEBUG|01|main|2020-05-08 13:51:24.369 EDT|SSLCipher.java:1978|KeyLimit write side: algorithm = AES/GCM/NOPADDING:KEYUPDATE
countdown value = 137438953472
javax.net.ssl|ALL|01|main|2020-05-08 13:51:24.382 EDT|X509Authentication.java:243|No X.509 cert selected for EC
javax.net.ssl|ALL|01|main|2020-05-08 13:51:24.382 EDT|X509Authentication.java:243|No X.509 cert selected for EC
javax.net.ssl|ALL|01|main|2020-05-08 13:51:24.382 EDT|X509Authentication.java:243|No X.509 cert selected for EC
javax.net.ssl|DEBUG|01|main|2020-05-08 13:51:24.414 EDT|SSLCipher.java:1978|KeyLimit write side: algorithm = AES/GCM/NOPADDING:KEYUPDATE
countdown value = 137438953472
javax.net.ssl|DEBUG|01|main|2020-05-08 13:51:24.417 EDT|SSLCipher.java:1824|KeyLimit read side: algorithm = AES/GCM/NOPADDING:KEYUPDATE
countdown value = 137438953472
GET / HTTP/1.1
Host: localhost:8443
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1
javax.net.ssl|ALL|01|main|2020-05-08 13:51:24.423 EDT|SSLSocketImpl.java:1002|Closing output stream
javax.net.ssl|DEBUG|01|main|2020-05-08 13:51:24.423 EDT|SSLSocketImpl.java:670|close outbound of SSLSocket
javax.net.ssl|ALL|01|main|2020-05-08 13:51:24.424 EDT|SSLSocketImpl.java:877|Closing input stream
javax.net.ssl|DEBUG|01|main|2020-05-08 13:51:24.425 EDT|SSLSocketImpl.java:636|close inbound of SSLSocket
javax.net.ssl|DEBUG|01|main|2020-05-08 13:51:24.425 EDT|SSLSocketImpl.java:473|duplex close of SSLSocket
javax.net.ssl|DEBUG|01|main|2020-05-08 13:51:24.425 EDT|SSLSocketImpl.java:1381|close the SSL connection (passive)
I wondered if this was no longer supported, but the help command suggests it is:
$ java11 -cp . -Djavax.net.debug=help javatester.SimpleHTTPSServer
(...snipped)
ssl turn on ssl debugging
The following can be used with ssl:
record enable per-record tracing
handshake print each handshake message
keygen print key generation data
session print session activity
(snipped...)
How can I export the premaster secret from jdk11 connections so I can use them in Wireshark?
If the newer Java versions do no longer output the pre-master secret you can use the project extract-tls-secrets.
Decrypt HTTPS/TLS connections on-the-fly. Extract the shared secrets from secure TLS connections for use with Wireshark. Attach to a Java process on either side of the connection to start decrypting.
The code of this project can be injected at start-up into the TLS server or client using the javaagent system, or you can connect to an existing Java process (I assume via Java debugger interface).
I am trying to login remotely into Domino with standalone Java program.
I have ncso.jar (and TrustedCerts.class) in classpath.
The DIIOP_IOR.TXT file is generated by the diiop task. If I copy the file contents directly into my program and try creating the session like this:
String ior = "IOR:....." // 404 bytes
Session session = NotesFactory.createSessionWithIOR(ior, "username", "password");
the result is:
org.omg.CORBA.COMM_FAILURE: java.net.ConnectException: connect: Address is invalid on local machine, or port is not valid on remote machine Host: poseidon.heeros.com Port: 0 vmcid: 0x0 minor code: 1 completed: No
The server name is valid but port 0 seems odd. I tried an online decoder at http://www2.parc.com/istl/projects/ILU/parseIOR/ and here is the result:
object key is <#048525651a-ec68-106c-eee0-007e2d2233b5#00LotusNOI#01#00#01>;
no trustworthy most-specific-type info; unrecognized ORB type;
reachable with IIOP 1.1 at host "poseidon.heeros.com", port 0
...which seems to confirm that the port is incorrect. I have specified the server URL in Internet Sites with an IIOP Site document but there is no field for port there.
Questions:
Where do I set the port that appears in diiop_ior.txt?
Which port should I specify? (I'm guessing 1352)
EDIT
Here is the result of tell diiop show config on server:
Dump of Domino IIOP (DIIOP) Configuration Settings
Full Server Name: CN=Afrodite/O=Heeros
Common Server Name: Afrodite/Heeros
Refresh Interval: 3 minutes
Host Full Name: poseidon.heeros.com
Host Short Name: poseidon
Host Address: 10.163.0.146
Public Host Name/Address: poseidon.heeros.com
TCP Port: 0 Disabled
SSL Port: 63149 Enabled
Initial Net Timeout: 120 seconds
Session Timeout: 60 minutes
Client Session Timeout: 62 minutes
Allow Ambiguous Names: True
Web Name Authentic: False
User Lookup View: ($Users)
Allow Database Browsing: False
Internet Sites: Enabled
Internet Site Name: Heeros
Site Config Loaded from: Domino IIOP and Web Internet Site documents
Site is Default: False
Site Public Host Name/Address: poseidon.heeros.com
Site IOR File: D:\Lotus\Domino\data\domino\html\diiop_ior.txt
Site SSL Key File: D:\Lotus\Domino\data\heeros.kyr
Site Java Key File: D:\Lotus\Domino\data\domino\java\TrustedCerts.class
Site TCP Name/Password Allowed: False
Site TCP Anonymous Allowed: False
Site SSL Name/Password Allowed: True
Site SSL Anonymous Allowed: True
Site Multi-Server Session Authentication: Enabled
Site Multi-Server Session Configuration: LtpaToken
Single Server Cookies: Disabled
It seems that the correct port number is 63148. It must be specified in Server Document at Ports --> Internet Ports --> DIIOP as "TCP/IP port number".
Additionally, in the IIOP Site document, the TCP Authentication must be allowed.
In my experience DIIOP doesn't use SSL/TLS at all. Only the DIIOP_IOR.TXT is downloaded via SSL/TLS. Capture your network traffic with Wireshark or something similar and monitor: port 63148 or port 63149. #lauri-laanti : Could you please test in your environment if the connection is encrypted with wireshark?
Wireshark Ourput: GIOP createSession with Username and Password (Blanked with X)
0000 00 50 56 69 f5 2b 00 50 56 c0 00 02 08 00 45 00 .PVi.+.PV.....E.
0010 00 c0 0d 06 40 00 80 06 bb ca c0 a8 58 01 c0 a8 ....#.......X...
0020 58 15 d2 e0 f6 ac ef b6 47 e8 13 10 53 10 50 18 X.......G...S.P.
0030 01 00 29 bb 00 00 47 49 4f 50 01 00 00 00 00 00 ..)...GIOP......
0040 00 8c 00 00 00 00 00 00 00 05 01 00 00 00 00 00 ................
0050 00 31 04 38 35 32 35 36 35 31 61 2d 65 63 36 38 .1.8525651a-ec68
0060 2d 31 30 36 63 2d 65 65 65 30 2d 30 30 37 65 32 -106c-eee0-007e2
0070 64 32 32 33 33 62 35 00 4c 6f 74 75 73 4e 4f 49 d2233b5.LotusNOI
0080 01 00 01 00 00 00 00 00 00 0e 63 72 65 61 74 65 ..........create
0090 53 65 73 73 69 6f 6e 00 00 00 00 00 00 00 00 00 Session.........
00a0 00 01 00 00 00 00 00 00 00 01 00 00 00 0f 00 00 ................
00b0 00 06 00 61 00 64 00 6d 00 69 00 6e 00 00 00 00 ...a.d.m.i.n....
00c0 00 06 00 XX XX XX XX XX XX XX XX XX XX 00 ...XXXXXXXXXX.
Java Code used:
_diiop_args = new String[]{"-ORBEnableSSLSecurity", "-HTTPEnableSSLSecurity"};
String ior = NotesFactory.getIOR(_diiop_host + ":" + _diiop_port,
_diiop_args, _user_name, _user_pass);
_session = NotesFactory.createSessionWithIOR(ior, _user_name, _user_pass);
I'm attempting to follow the instructions on this page:
http://www.mkyong.com/webservices/jax-ws/suncertpathbuilderexception-unable-to-find-valid-certification-path-to-requested-target/
to create a certificate for my localhost in which to do some development testing.
When running InstallCert for localhost:8443, the following two certificates are generated:
Server sent 2 certificate(s):
1 Subject CN=localhost4.localdomain4, O=example.com, C=US
Issuer CN=Certificate Shack, O=example.com, C=US
sha1 f4 2a a9 09 32 a6 ee 41 9d 9c 44 e6 4a bc 31 79 17 cb 88 fd
md5 e0 78 65 83 30 33 78 c5 80 17 e7 7a a2 91 85 52
2 Subject CN=Certificate Shack, O=example.com, C=US
Issuer CN=Certificate Shack, O=example.com, C=US
sha1 b8 87 d6 2d ac d8 36 06 7c 58 68 10 3e 21 39 6a a0 33 a1 25
md5 07 24 57 5f f8 35 1e 97 70 ff 54 aa 13 e6 6b 12
The trouble is that my system needs the CN to be localhost. I have no idea where the localhost4.localdomain4 comes from. How can I change this to be simply localhost?
The certificate comes from the server, during the handshake.
The CN is inside the certificate.
You can't change it without creating a new server certificate.
I try to connect to a Domino Server with a remote Java application started from Eclipse. The Domino Server allows SSL connections only.
I try to get the session with the following code.
String[] arg = new String[1];
arg[0] = "-ORBEnableSSLSecurity";
String IOR = NotesFactory.getIOR(DOMINO_SERVER);
session = NotesFactory.createSessionWithIOR(IOR);
I get the following error message:
Could not get IOR from Domino Server: http:///diiop_ior.txt
I also checked if the URL works in a browser. If I put the URL in a browser I get the correct response from the server.
The TrustedCert.class from the Domino server is included in my Eclipse project.
Here some configuration details from the "diiopcfg.txt":
TCP Port: 0 Disabled
SSL Port: 63149 Enabled
Site TCP Name/Password Allowed: True
Site TCP Anonymous Allowed: False
Site SSL Name/Password Allowed: True
Site SSL Anonymous Allowed: False
Site Multi-Server Session Authentication: Disabled
[Update]
Enabled TCP Port 63148, now I get a session but cannot open a database. Error message NotesException: Database open failed () Only when I access the port directly I get a session object.
[Update 2]
Get the session now. Can't open the database.
Error message: NotesException: Database ... has not been opened yet.
If I use the "open" method of the Database object => Error message: Database open failed()
Database db = session.getDatabase(DOMINO_SERVER, DOMINO_DATABASE);
db.open();
ACL is correct, Maximum internet name and password = Reader
Any idea why the database could not be opened. Tried another database with the same result.
Try the following to connect to SSL.
String args[] = new String[1];
args[0] = "-ORBEnableSSLSecurity";
Session s = NotesFactory.createSession(host, args, user, pwd);
Another method to connect:
String args[] = new String[1];
args[0] = "-HTTPEnableSSLSecurity";
String ior = NotesFactory.getIOR(host,args);
s = NotesFactory.createSessionWithIOR(ior, user, pwd);
The variable host should just be the host name and nothing else. Your diiop_ior.txt needs to be visible on SSL though (so check that first).
Alternatively you can try accessing the port 63148 directly. For example.
s = NotesFactory.createSession( "server:63148", user, pwd);
But this can move depending on server configuration.
Lastly you can pull the DIIOP_IOR.txt and use it directly. Same issue as previous alternative though.
Sorry, this answer is almost a duplicate to this answer but is so important, that I think the text needs to be quoted in this post.
In my experience DIIOP doesn't use SSL/TLS at all. Only the DIIOP_IOR.TXT is downloaded via SSL/TLS. Capture your network traffic with Wireshark or something similar and monitor: port 63148 or port 63149. #michael-schlömp : Could you please test in your environment if the connection is encrypted with wireshark?
Wireshark Ourput: GIOP createSession with Username and Password (Blanked with X)
0000 00 50 56 69 f5 2b 00 50 56 c0 00 02 08 00 45 00 .PVi.+.PV.....E.
0010 00 c0 0d 06 40 00 80 06 bb ca c0 a8 58 01 c0 a8 ....#.......X...
0020 58 15 d2 e0 f6 ac ef b6 47 e8 13 10 53 10 50 18 X.......G...S.P.
0030 01 00 29 bb 00 00 47 49 4f 50 01 00 00 00 00 00 ..)...GIOP......
0040 00 8c 00 00 00 00 00 00 00 05 01 00 00 00 00 00 ................
0050 00 31 04 38 35 32 35 36 35 31 61 2d 65 63 36 38 .1.8525651a-ec68
0060 2d 31 30 36 63 2d 65 65 65 30 2d 30 30 37 65 32 -106c-eee0-007e2
0070 64 32 32 33 33 62 35 00 4c 6f 74 75 73 4e 4f 49 d2233b5.LotusNOI
0080 01 00 01 00 00 00 00 00 00 0e 63 72 65 61 74 65 ..........create
0090 53 65 73 73 69 6f 6e 00 00 00 00 00 00 00 00 00 Session.........
00a0 00 01 00 00 00 00 00 00 00 01 00 00 00 0f 00 00 ................
00b0 00 06 00 61 00 64 00 6d 00 69 00 6e 00 00 00 00 ...a.d.m.i.n....
00c0 00 06 00 XX XX XX XX XX XX XX XX XX XX 00 ...XXXXXXXXXX.
Java Code used:
_diiop_args = new String[]{"-ORBEnableSSLSecurity", "-HTTPEnableSSLSecurity"};
String ior = NotesFactory.getIOR(_diiop_host + ":" + _diiop_port,
_diiop_args, _user_name, _user_pass);
_session = NotesFactory.createSessionWithIOR(ior, _user_name, _user_pass);
If you download and analyse the DIIOP_IOR.TXT with the ILU IOR Parser you will see there is no SSL/TLS information nor port in the IOR File.
SSL/TLS only version:
object key is <#048525651a-ec68-106c-eee0-007e2d2233b5#00LotusNOI#01#00#01>;
no trustworthy most-specific-type info; unrecognized ORB type;
reachable with IIOP 1.1 at host "testdom01.jjtest.site", port 0
SSL/TLS and non SSL/TLS version:
object key is <#048525651a-ec68-106c-eee0-007e2d2233b5#00LotusNOI#01#00#01>;
no trustworthy most-specific-type info; unrecognized ORB type;
reachable with IIOP 1.1 at host "testdom01.jjtest.site", port 63148
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"?>
[…]
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.
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.
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