I'm using commons-net 3.7 and OpenJDK 11. FTP server is TLSv1.2 implicit.
I can retrieve files but when I try to storeFile it hangs. As I checked the socket.close(); method call at storeFile waits input.
I tried copying InputStream to OutputStream way. Same thing happens when I try to close the OutputStream. It waits and same error occurs.
Why it cannot close socket and end storing file? Thank you.
FTPSClient ftpsClient = new FTPSClient(true);
ftpsClient.connect("host", 990);
ftpsClient.enterLocalPassiveMode();
ftpsClient.setFileType(FTP.BINARY_FILE_TYPE);
ftpsClient.setControlKeepAliveTimeout(300);
ftpsClient.setBufferSize(1024000);
ftpsClient.login("user", "password");
// login is successful, everything seems fine
InputStream inputstream = new FileInputStream("test.pdf");
ftpsClient.storeFile("/upload", inputstream);
// waits 4-5 minutes and gets connection reset
// I can retrieve and delete files, only uploading is problem.
09B0: 62 6A 47 BA 9F F4 9B 74 BE E0 07 0B F5 63 92 C0 bjG....t.....c..
09C0: 2C 26 B6 36 98 3C 83 D4 A4 3F 3C 99 72 6B 24 45 ,&.6.<...?<.rk$E
09D0: FE 9F 3E F4 DA 3B CB B2 18 12 F0 FB 85 ..>..;.......
)
javax.net.ssl|ALL|01|main|2020-09-01 01:31:25.414 CEST|SSLSocketImpl.java:1002|Closing output stream
javax.net.ssl|DEBUG|01|main|2020-09-01 01:31:25.415 CEST|SSLSocketImpl.java:670|close outbound of SSLSocket
javax.net.ssl|DEBUG|01|main|2020-09-01 01:31:25.417 CEST|SSLSocketOutputRecord.java:71|WRITE: TLS12 alert(close_notify), length = 10
javax.net.ssl|DEBUG|01|main|2020-09-01 01:31:25.418 CEST|SSLCipher.java:1727|Plaintext before ENCRYPTION (
0000: 01 00 ..
)
javax.net.ssl|DEBUG|01|main|2020-09-01 01:31:25.418 CEST|SSLSocketOutputRecord.java:85|Raw write (
0000: 15 03 03 00 1A 00 00 00 00 00 00 00 11 1B EB DE ................
0010: 1F A8 2E 8B DE 84 26 1F FD E6 23 C4 81 E7 BC ......&...#....
)
javax.net.ssl|DEBUG|01|main|2020-09-01 01:31:25.418 CEST|SSLSocketImpl.java:473|duplex close of SSLSocket
javax.net.ssl|DEBUG|01|main|2020-09-01 01:31:25.418 CEST|SSLSocketImpl.java:1361|close the underlying socket
javax.net.ssl|DEBUG|01|main|2020-09-01 01:31:25.419 CEST|SSLSocketImpl.java:1380|close the SSL connection (initiative)
javax.net.ssl|DEBUG|01|main|2020-09-01 01:31:25.419 CEST|SSLSocketImpl.java:1408|wait for close_notify or alert
javax.net.ssl|ERROR|01|main|2020-09-01 01:38:14.945 CEST|TransportContext.java:313|Fatal javax.net.ssl|WARNING|01|main|2020-09-01 01:38:14.947 CEST|SSLSocketImpl.java:494|SSLSocket duplex close failed (
"throwable" : {
javax.net.ssl.SSLProtocolException: Connection reset
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:126)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:259)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:137)
at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
at java.base/sun.security.ssl.SSLSocketImpl.waitForClose(SSLSocketImpl.java:1413)
at java.base/sun.security.ssl.SSLSocketImpl.closeSocket(SSLSocketImpl.java:1389)
at java.base/sun.security.ssl.SSLSocketImpl.shutdown(SSLSocketImpl.java:1370)
at java.base/sun.security.ssl.SSLSocketImpl.bruteForceCloseInput(SSLSocketImpl.java:603)
at java.base/sun.security.ssl.SSLSocketImpl.duplexCloseInput(SSLSocketImpl.java:583)
at java.base/sun.security.ssl.SSLSocketImpl.close(SSLSocketImpl.java:484)
at org.apache.commons.net.ftp.FTPClient._storeFile(FTPClient.java:686)
at org.apache.commons.net.ftp.FTPClient.__storeFile(FTPClient.java:645)
at org.apache.commons.net.ftp.FTPClient.storeFile(FTPClient.java:2037)
at my.project.package.util.FTPUtil.main(FTPUtil.java:51)
Caused by: java.net.SocketException: Connection reset
at java.base/java.net.SocketInputStream.read(SocketInputStream.java:186)
at java.base/java.net.SocketInputStream.read(SocketInputStream.java:140)
at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:448)
at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:165)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108)
... 11 more}
425 Data channel timed out due to not meeting the minimum bandwidth requirement.
SERVER: 425 Data channel timed out due to not meeting the minimum bandwidth requirement.
Related
I want to establish a tls connection between my sim card and a server in TLS-PSK mode. to achive this, as far as I understood, First I have to send a push command to open a BIP channel, then establish a CAT_TP link by sending another push command and then sim card will start the TLS handshake. So first I want to send a push command to my sim card to open a BIP channel. To do this, the push command will be OPEN CHANNEL command. But first I'm testing this process by sending the OPEN CHANNEL command to sim card via sim card reader to see how it works. I have a sample file which I'm following that first sends an envelope SMS-PP with the following content:
81488346 \
84 44\ ;Connection parameter tag
81 03 014001\ ;Command details TLV
82 02 8182\ ;Device identities TLV
35 01 03\ ;Bearer description TLV: default
39 02 0514\ ;Buffer size TLV
47 14 13696E7465726E65742D656E7472657072697365\ ;Network Access Name
0D 07 xxxxxxxxxxxxxx\ ;login name
0D 07 xxxxxxxxxxxxxx\ ;password
3C 03 021964\ ; UICC/terminal interface port number
3E 05 xxxxxxxxxx ;IP address
in sample file it ciphers the above content by sim card's keys and it's RAM TAR value and sends the ciphered data by an envelope command like this:
Command : 80 C2 00 00 8A
Input Data : D1 81 87 02 02 82 81 06 02 80 01 8B 7D 40 05 81
: 12 50 F3 96 F6 22 22 22 22 22 22 22 6D 02 70 00
: 00 68 15 16 39 12 12 00 00 01 F0 BD C0 49 B4 0C
: EB A9 7C 4B 04 32 17 BE A7 2F DA AC 70 93 36 73
: 83 FD AC 64 CA 9B 34 9C 2B E6 31 24 A0 D5 11 09
: 00 3E E3 F5 43 4B 55 77 98 E5 08 40 A4 CE A9 52
: 3E E1 38 6B 44 AC 73 1E 3B CD 49 32 92 B2 C3 22
: 25 02 68 90 FD F5 06 23 97 0D BD 5B 1D DE 25 F1
: FD 4C 75 C8 37 AC B0 15 05 25
Then it fetches the push sms via a FETCH command and after that get the terminal response with TERMINAL RESPONSE command to see if everything went ok. and finally fetches the open channel with the FETCH command and it says once OPEN CHANNEL is done, card sends CLIENT HELLO to the server to start the TLS handshake.
Now I want to implement this but at the first step, where I should send the envelope, I expect to get 9146 as status word which means everything was ok. but I get 6200 which means "State of non-volatile memory is unchanged".
Why do I get this respnse? And basically what is the proper way to open a BIP channel and then stablish a CAT-TP link?
You should first send the TERMINAL PROFILE command. With this command, you'll let the UICC know what the terminal is capable of. In this command, you should indicate that the terminal is capable of handling PROACTIVE commands. You can read more about this in ETSI TS 102223
I have two queue manager servers running on two boxes. QM1 has a sender channel defined , and QM2 has a receiver channel with the same name.
I have created self signed certificate for each QM , extracted and added the public part of each certificate to the other QM's key db. Altered each channel to use CipherSpec TRIPLE_DES_SHA_US.
This setup works perfectly fine, if QM names don't contain any special character. If name of the sender QM is A_QM and the other one is B_QM , the sender channel never comes up and is in RETRYING state.
while creating self-signed certificate I am using label ibmwebspheremqa_qm
in case of A_QM and ibmwebspheremqqm1 when the queue manager is QM1. Similarly when adding the public part of the certificate I am preserving the other QM's label. This is the only difference in the whole setup.
Is there any restriction in defining QM names if I want to configure SSL or TLS ?
I had no trouble creating a pair of QMgrs and channels as described and getting them to run:
[mqm#rhel6base scripts]$ runmqsc A_QM
5724-H72 (C) Copyright IBM Corp. 1994, 2014.
Starting MQSC for queue manager A_QM.
dis chs(*) all
1 : dis chs(*) all
AMQ8417: Display Channel Status details.
CHANNEL(A_QM.B_QM) CHLTYPE(SDR)
BATCHES(0) BATCHSZ(50)
BUFSRCVD(1) BUFSSENT(1)
BYTSRCVD(268) BYTSSENT(268)
CHSTADA(2015-04-01) CHSTATI(10.57.43)
COMPHDR(NONE,NONE) COMPMSG(NONE,NONE)
COMPRATE(0,0) COMPTIME(0,0)
CONNAME(127.0.0.1(3115)) CURLUWID(0C031C5501020010)
CURMSGS(0) CURRENT
CURSEQNO(0) EXITTIME(0,0)
HBINT(300) INDOUBT(NO)
JOBNAME(0000130700000001) LOCLADDR(127.0.0.1(53145))
LONGRTS(999999999) LSTLUWID(0000000000000000)
LSTMSGDA( ) LSTMSGTI( )
LSTSEQNO(0) MCASTAT(RUNNING)
MONCHL(OFF) MSGS(0)
NETTIME(0,0) NPMSPEED(FAST)
RQMNAME(B_QM) SHORTRTS(10)
SSLCERTI(CN=rhel6base.ioptconsulting.com)
SSLKEYDA( ) SSLKEYTI( )
SSLPEER(SERIALNUMBER=55:1C:06:B2,CN=rhel6base.ioptconsulting.com)
SSLRKEYS(0) STATUS(RUNNING)
STOPREQ(NO) SUBSTATE(MQGET)
XBATCHSZ(0,0) XMITQ(B_QM)
XQTIME(0,0) RVERSION(08000001)
RPRODUCT(MQMM)
[mqm#rhel6base ssl]$ runmqakm -cert -list -db key.kdb -stashed
Certificates found
* default, - personal, ! trusted, # secret key
! ibmwebspheremqb_qm
*- ibmwebspheremqa_qm
[mqm#rhel6base ssl]$ runmqakm -cert -list -db ../../B_QM/ssl/key.kdb -stashed
Certificates found
* default, - personal, ! trusted, # secret key
! ibmwebspheremq_a_qm
*- ibmwebspheremqb_qm
[mqm#rhel6base ssl]$
REFRESH SECURITY TYPE(SSL)
The most likely cause for the behavior you are seeing is not issuing refresh security or restarting the QMgrs after updating their keystores. For example:
echo "REFRESH SECURITY TYPE(SSL)" | runmqsc A_QM
echo "REFRESH SECURITY TYPE(SSL)" | runmqsc B_QM
or
endmqm -i A_QM; strmqm A_QM
endmqm -i B_QM; strmqm B_QM
One aspect of security for the keystore is that there is only ever one version of it in memory at a time. If it were possible for one channel to have one version and another channel to have another version, it would become impossible to determine which was the "right" one in order to detect tampering. So when the KDB is updated, the refresh security command causes the QMgr to stop all running TLS channels, dump the KDB from memory, and reload the KDB when one of the channels starts.
(MQ doesn't use SSL, by the way, never has. It uses TLS with SSL ciphers and now that SSL itself is broken, best to get used to saying TLS because that will help to remember to use TLS ciphers exclusively going forward.)
So after updating the KDB if you did not run the refresh, it is likely that the refresh was not done and the QMgr doesn't yet know about the newly added certificate for the remote QMgr.
When SSLCAUTH(OPTIONAL) is not optional
Another common problem with TLS is a misunderstanding of SSLCAUTH(OPTIONAL). Many people believe that this always results in one-way authentication so they set SSLCAUTH(OPTIONAL) and then exchange certs in only one direction. For example, QM1 has TLS channels to QM2 so obviously has its own personal certificate. Then we try to connect A_QM to it. We import A_QM's personal cert to QM1's KDB, refresh security everywhere, DEF CHL(A_QM.QM1) ... SSLCAUTH(OPTIONAL) on both sides and try to start the channel.
The misunderstanding is that if the thing initiating the channel has a personal cert it will send it in all cases. To test with SSLCAUTH(OPTIONAL) requires removing any personal cert from the keystore on the side initiating the connection. Often people do not realize this and spend many hours (in some cases weeks) struggling to understand why this fails.
For your purposes always exchange the personal certs in both directions.
Incomplete cert exchange
The other common problem working with self-signed certs is when a cert is generated multiple times with the same label and/or CN value and there's a mismatch between the personal cert on one end versus the public portion on the other. This is easily checked by viewing the cert details and checking that the fingerprint and other details match like so:
[mqm#rhel6base ssl]$ runmqakm -cert -details -label ibmwebspheremqb_qm -db key.kdb -stashed
Label : ibmwebspheremqb_qm
Key Size : 1024
Version : X509 V3
Serial : 551c06b2
Issuer : CN=rhel6base.ioptconsulting.com
Subject : CN=rhel6base.ioptconsulting.com
Not Before : April 1, 2015 10:54:42 AM EDT
Not After : March 31, 2016 10:54:42 AM EDT
Public Key
30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01
05 00 03 81 8D 00 30 81 89 02 81 81 00 DF 0F 90
8C C2 CA D1 ED 16 E2 A8 DA E3 26 63 45 4B B2 29
37 04 65 A1 D3 30 23 2A 67 AB 61 06 75 E1 8B 87
D2 9A CD 38 4C 63 D6 CC AD 25 55 B3 8B BE 34 4E
32 CB EB FE E2 5D E0 49 2F 57 AC EC 5E 79 A2 52
F6 21 5A 5F 95 AB C4 70 C8 00 68 0B 22 32 8C 1F
4C DB 0C D9 85 B8 06 5A 7C DA 3A 3A BE 12 C8 C1
C0 92 5E FE 09 46 F7 E1 1F 3D 4A AA 63 F0 80 09
3D FE E7 A4 49 5D 86 09 4C B5 0E 1E 97 02 03 01
00 01
Public Key Type : RSA (1.2.840.113549.1.1.1)
Fingerprint : SHA1 :
55 FC 2C 7C 00 8E A7 27 78 0D 99 AD FF 84 58 57
BF 16 1C 62
Fingerprint : MD5 :
90 66 AD 5D 71 AF 75 E8 9A 4A A3 5A DB 15 CD 21
Fingerprint : SHA256 :
7E 43 75 25 31 ED E7 76 FA 40 87 37 F3 B2 9E 6F
2D 55 2D 3C CB 52 60 9C 85 B2 53 F3 1C C0 D2 3C
Extensions
AuthorityKeyIdentifier
keyIdentifier: 8D BC 64 AF D9 12 02 34
authorityIdentifier:
authorityCertSerialNumber:
SubjectKeyIdentifier
keyIdentifier: 8D BC 64 AF D9 12 02 34
Signature Algorithm : SHA1WithRSASignature (1.2.840.113549.1.1.5)
Value
46 D4 8A D9 62 04 CF C4 0E 23 DB 4C F9 AD 25 9B
89 3B FD B9 4F 52 4C DE 36 96 15 92 0E 7B 03 05
E8 85 12 AD E7 40 DB E9 4D 77 8F B7 4B CC 43 1B
AD 6D 13 B1 2F 26 12 C8 1C 17 FE 51 A7 B7 7B EE
80 CA 82 37 98 E1 B4 17 3A B4 CC 20 E7 4E 53 42
C6 E1 C3 1C 54 BD DC 9A 14 86 9A 25 66 AC 11 2C
78 A0 B5 DC 22 FE 52 62 59 27 02 DA 82 07 64 42
38 99 8A A7 52 53 20 C3 B2 FF 8F 6D A6 A3 8F 72
Trust Status : Enabled
[mqm#rhel6base ssl]$ runmqakm -cert -details -label ibmwebspheremqb_qm -db ../../B_QM/ssl/key.kdb -stashed
Label : ibmwebspheremqb_qm
Key Size : 1024
Version : X509 V3
Serial : 551c06b2
Issuer : CN=rhel6base.ioptconsulting.com
Subject : CN=rhel6base.ioptconsulting.com
Not Before : April 1, 2015 10:54:42 AM EDT
Not After : March 31, 2016 10:54:42 AM EDT
Public Key
30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01
05 00 03 81 8D 00 30 81 89 02 81 81 00 DF 0F 90
8C C2 CA D1 ED 16 E2 A8 DA E3 26 63 45 4B B2 29
37 04 65 A1 D3 30 23 2A 67 AB 61 06 75 E1 8B 87
D2 9A CD 38 4C 63 D6 CC AD 25 55 B3 8B BE 34 4E
32 CB EB FE E2 5D E0 49 2F 57 AC EC 5E 79 A2 52
F6 21 5A 5F 95 AB C4 70 C8 00 68 0B 22 32 8C 1F
4C DB 0C D9 85 B8 06 5A 7C DA 3A 3A BE 12 C8 C1
C0 92 5E FE 09 46 F7 E1 1F 3D 4A AA 63 F0 80 09
3D FE E7 A4 49 5D 86 09 4C B5 0E 1E 97 02 03 01
00 01
Public Key Type : RSA (1.2.840.113549.1.1.1)
Fingerprint : SHA1 :
55 FC 2C 7C 00 8E A7 27 78 0D 99 AD FF 84 58 57
BF 16 1C 62
Fingerprint : MD5 :
90 66 AD 5D 71 AF 75 E8 9A 4A A3 5A DB 15 CD 21
Fingerprint : SHA256 :
7E 43 75 25 31 ED E7 76 FA 40 87 37 F3 B2 9E 6F
2D 55 2D 3C CB 52 60 9C 85 B2 53 F3 1C C0 D2 3C
Extensions
AuthorityKeyIdentifier
keyIdentifier: 8D BC 64 AF D9 12 02 34
authorityIdentifier:
authorityCertSerialNumber:
SubjectKeyIdentifier
keyIdentifier: 8D BC 64 AF D9 12 02 34
Signature Algorithm : SHA1WithRSASignature (1.2.840.113549.1.1.5)
Value
46 D4 8A D9 62 04 CF C4 0E 23 DB 4C F9 AD 25 9B
89 3B FD B9 4F 52 4C DE 36 96 15 92 0E 7B 03 05
E8 85 12 AD E7 40 DB E9 4D 77 8F B7 4B CC 43 1B
AD 6D 13 B1 2F 26 12 C8 1C 17 FE 51 A7 B7 7B EE
80 CA 82 37 98 E1 B4 17 3A B4 CC 20 E7 4E 53 42
C6 E1 C3 1C 54 BD DC 9A 14 86 9A 25 66 AC 11 2C
78 A0 B5 DC 22 FE 52 62 59 27 02 DA 82 07 64 42
38 99 8A A7 52 53 20 C3 B2 FF 8F 6D A6 A3 8F 72
Trust Status : Enabled
Debugging
Check the error logs. In particular, it is good security design to give an attacker as little information as possible to always check the logs of the QMgr that is receiving the connection first. If it has detected the error it will have detailed logs and the sending side will have sparse logs like "the remote QMgr disconnected" which doesn't reveal much to an attacker.
If the error is actually on the sending side, then it will have most detailed error messages and the receiving side will have little or none. For example, if the sending side can't find its stash file the connection isn't ever attempted and the receiving side will have no record of the event.
Finally, there is always the possibility that you may discover a bug working with GSKit and MQ, or that you are trying to use features not relevant to version of MQ that you are working on. For this reason, it is always best to include a dspmqver -a in your question. If after all of this, you still can't get it to work, please update the question with the dspmqver -a output and the results of your further testing.
In summary
To sum up:
QMgr names like A_QM are perfectly valid.
First make sure that the QMgrs have picked up their new KDB files after changes by restarting the QMgrs or running REFRESH SECURITY TYPE(SSL).
Make sure to exchange certs in both directions every time.
Check the error logs on both sides starting with the side receiving the connection request.
Always include output from dspmqver -a when requesting help with GSKit, certs or TLS since the behavior varies by version and fix pack.
I am working in establishing a secure communication channel between a java server and a tls client. During the handshake, all goes well, the client Hello and server Hello messages are correct. Moreover, they both generate the same master secret for the engaged session. But at the really end of the handshake, server throws an exception telling "Ciphertext sanity check fails".
Client trace
0050 - 34 68 ed 2f 6e 4h./n
>>> TLS 1.2 ChangeCipherSpec [length 0001]
01
write to 0x1878b98 [0x18891f0] (6 bytes => 6 (0x6))
0000 - 14 03 03 00 01 01 ......
>>> TLS 1.2 Handshake [length 0010], Finished
14 00 00 0c 14 54 0c 4d c0 22 62 90 c2 92 a1 d1
write to 0x1878b98 [0x18891f0] (45 bytes => 45 (0x2D))
0000 - 16 03 03 00 28 b7 76 bd-36 cd cd eb 8d 9f 34 46 ....(.v.6.....4F
0010 - 25 f7 61 cc cd a3 8e af-6d da 14 60 3c 0f 50 21 %.a.....m..`<.P!
0020 - f4 cc 7a a4 af cf 75 d8-48 54 ee b9 44 ..z...u.HT..D
read from 0x1878b98 [0x187f7e3] (5 bytes => 5 (0x5))
0000 - 15 03 03 00 02 .....
read from 0x1878b98 [0x187f7e8] (2 bytes => 2 (0x2))
0000 - 02 28 .(
<<< TLS 1.2 Alert [length 0002], fatal handshake_failure
02 28
Server's side:
[Raw read]: length = 5
0000: 14 03 03 00 01 .....
[Raw read]: length = 1
0000: 01 .
Thread-0, READ: TLSv1.2 Change Cipher Spec, length = 1
[Raw read]: length = 5
0000: 16 03 03 00 28 ....(
[Raw read]: length = 40
0000: B7 76 BD 36 CD CD EB 8D 9F 34 46 25 F7 61 CC CD .v.6.....4F%.a..
0010: A3 8E AF 6D DA 14 60 3C 0F 50 21 F4 CC 7A A4 AF ...m..`<.P!..z..
0020: CF 75 D8 48 54 EE B9 44 .u.HT..D
Thread-0, READ: TLSv1.2 Handshake, length = 40
%% Invalidated: [Session-1, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256]
Thread-0, SEND TLSv1.2 ALERT: fatal, description = handshake_failure
Thread-0, WRITE: TLSv1.2 Alert, length = 2
[Raw write]: length = 7
0000: 15 03 03 00 02 02 28 ......(
Thread-0, called closeSocket()
Thread-0, handling exception: javax.net.ssl.SSLHandshakeException: ciphertext sanity check failed
What I can not understand is why the server is launching such exception while it succeeds in decrypting the ChangeCipherSpec message sent from the client? What could be the reason for such exception?
N.B: I already check and they both derived the same master key, here it is:
Server's side
CONNECTION KEYGEN:
Client Nonce:
0000: 48 B2 6C 02 B1 40 0B D9 6E 14 EB 7A 93 7D 2F 07 H.l..#..n..z../.
0010: 90 CF 1E 5D 65 8A 66 89 54 D4 60 50 BD AC AB 34 ...]e.f.T.`P...4
Server Nonce:
0000: 54 FD 9A E3 BB D4 15 61 A6 0C D3 30 FA 07 0A 16 T......a...0....
0010: 79 A8 79 0B 0A 81 00 95 9C CA C0 7A F1 FF 37 E7 y.y........z..7.
Master Secret:
0000: 39 5B EB 11 66 09 25 B5 6D E4 C7 86 E4 3E 10 BB 9[..f.%.m....>..
0010: B4 F0 D9 B7 BD 7D 8F AD 58 38 31 42 B6 90 53 AD ........X81B..S.
0020: 54 46 36 DC F5 75 8A 9D 77 58 D5 24 6C 96 90 02 TF6..u..wX.$l...
Client's side
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-ECDSA-AES128-GCM-SHA256
Session-ID: 54FD9AE3A3B3BF807F408FA830641F850702E986C27FC631AF8E8E3097038166
Session-ID-ctx:
Master-Key: 395BEB11660925B56DE4C786E43E10BBB4F0D9B7BD7D8FAD58383142B69053AD544636DCF5758A9D7758D5246C969002
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
Thanks in advance to you guys.
My application is using SSL over SMTP.
But I faced a problem of extra byte at the end.
The packet which I recieved is as follows: (Hex dump of SSL Record packet)
17 03 01 01 00 9A 07 74 E3 4B E0 07 17 71 38 BF 29 7E 70
E9 14 CC B1 97 77 4C B9 AB A0 9F 88 7B D4 ED 14 8E 97 F2
5A BE 46 56 D4 12 BC 15 01 49 EE CE A1 ED 3F D3 6E 7F AA
DC 6B DF 41 11 74 7B 55 B8 D3 3E 8D EF 96 52 B0 BD 50 35
09 E7 2A FF 0E 39 58 C7 91 99 95 22 6F B0 73 57 28 B4 EA
C6 28 4C DC 5C DA 6C 31 FB 63 71 7D 08 F0 DD 78 C4 08 C5
27 90 04 C7 09 59 E4 83 F4 4D 9A 7B 65 E9 AF 38 44 B4 CD
9E 4D BE 80 0D 07 24 8D C3 79 99 DC 02 81 D7 97 21 16 0B
28 44 82 ED E4 5F E6 91 81 A5 28 C1 C8 92 60 36 4E DE 27
AF D0 2B EE FB 9D 12 9C 2B 4F 3F 29 F2 04 8F DC 21 39 4F
80 23 7E 78 3C A0 29 E0 67 E7 9F 90 B6 1F D4 08 63 3E CE
73 E1 17 72 8D B1 8C 3D A8 59 C0 0F 03 59 7A A6 5D F9 7A
40 57 D6 8D 94 48 93 BF D8 17 C6 70 79 36 13 D0 F1 D1 D2
69 D4 05 9D 67 86 6D E9 66 D0 83 4A D8 5E 20
The length of this packet as seen from SSL 3.1 protocol is 256 Bytes.
But there is one extra byte at the end (shown in bold at the end).
Due to this extra byte at the end, when next packet is being read, then this 20 is also read and causes error of SSL_R_WRONG_VERSION_NUMBER (I am using OpenSSL Library for SSL).
Next packet which I recieved is like (as per packet sniffer)
17 03 01 00 18 ...
But when next read is being done, OpenSSL reads packet as 20 17 03 01 .. which causes the error (since 17 03 is wrong version for 03 01)
I would like to know if this (extra byte at the end) is a part of SSL standard.
Please suggest me how to handle this case in OpenSSL. OpenSSL version is 1.0.0.
No. The extra byte is not as a part of SSL Standard.
As per SSL Standard (RFC 2246 for TLS 1.0, Latest is RFC 5246 for TLS 1.2) the record of SSL is as below:
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (CipherSpec.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
} fragment;
} TLSCiphertext;
The fragment will be exactly of the length as specified by uint16 length member. So, the 20 must be getting inserted either incorrectly by the Server Implementation, or some other software in the middle is inserting it when the data is in network.
Openssl reads exactly the number of bytes as specified by uint16 length member which is why it doesn't read 20.
Some of the points which you can focus on are:
1. Does this happen with the first application data packet which is transferred immediately after handshake? (From the content type I assumed this packet dump is for application data)
2. Is this a random occurance? Do all connections with that particular server exhibit the same behavior?
3. You can try to get the dump of the packet sent at the Server to see if 20 is present when the packet is being sent at the Server side itself or it is getting added during it's flight.
4. Could there be a Firewall related problem? (I don't know about Firewall, so didn't give more details here)
Hope this helps!
I was bashing my head with this one today; finally resorted to this:
_sslStream.Write(merged, 0, merged.Length - 1)
Problem solved, move along!
I capture packets sent/received by Win Xp machine when connecting to SQL Server 2005 Express using TLS encryption.
Server and Client exchange Hello messages
Server and Client send ChangeCipherSpec message
Then Server and Client server send strange message that is not described in TLS protocol
What is the message?
Server side capture:
16 **SSL Handshake**
03 01
00 4a
02 ServerHello
00 00 46
03 01
4b dd 68 59 GMT
33 13 37 98 10 5d 57 9d ff 71 70 dc d6 6f 9e 2c Random[00..13]
cb 96 c0 2e b3 2f 9b 74 67 05 cc 96 Random[14..27]
20 72 26 00 00 0f db 7f d9 b0 51 c2 4f cd 81 4c Session ID
3f e3 d2 d1 da 55 c0 fe 9b 56 b7 6f 70 86 fe bb Session ID
54 Session ID
00 04 Cipher Suite
00 Compression
14 03 01 00 01 01 **ChangeCipherSpec**
16 03 01 ???? Finished ???
00 20 d0 da cc c4 36 11 43 ff 22 25 8a e1 38 2b ???? ???
71 ce f3 59 9e 35 b0 be b2 4b 1d c5 21 21 ce 41 ???? ???
8e 24
16 03 01
00 20 d0 da cc c4 36 11 43 ff 22 25 8a e1 38 2b
71 ce f3 59 9e 35 b0 be b2 4b 1d c5 21 21 ce 41
8e 24
This message is already encrypted, therefore to see
14 03 01 00 00 0c
it needs to be decrypted first