SSL client program


S

Stone

Dear developers,

I am trying to write some client program which will open port 5000 on
the client side and connect to the computer where is run daemon which
listen on the port 5000.
Those port should be secured over SSL.
I have build up the C++ daemon which listen on that port together with
SSL and when I am writing
command:
openssl s_client -ssl3 -connect 192.168.0.120:9000
then in the log of daemon I can see that connection was establish and
working correctly.
Including server certificate, SSL handshake and Secure Renegotiation

I would like to created some client in Java but there I have some
problems.
When I run Java client application the in the daemon I see message:

24741:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
number:s3_pkt.c:295:

My Java code is:
/*
* To change this template, choose Tools | Templates
* and open the template in the editor.
*/
package ssltest;

import java.io.*;
import java.net.*;
import java.util.*;
import javax.net.ssl.*;
import java.security.cert.*;
/**
*
*/
public class SSLTest {

private int port = 5000;
private SSLSocketFactory sslSocketFactory;
private SSLSocket connection;
private SSLContext sslContext;
private TrustManager[] trustManager;
private PrintWriter outStream;
private BufferedReader inStream;
/**
* @param args the command line arguments
*/
public static void main(String[] args) {
// TODO code application logic here
System.out.println("Start");
SSLTest e = new SSLTest();
}

public SSLTest()
{
System.out.println("Connecting to 192.168.0.120 to port
5000");
connectTo();
}
private void initializeSSLContext() throws Exception {
try {
sslContext = SSLContext.getInstance("SSLv3");
System.out.println("Contents with TLSv1 was initiated");
sslContext.init(null, trustManager, new
java.security.SecureRandom());
System.out.println("Contents with TLSv1 was initiated with
trustManager");

HttpsURLConnection.setDefaultSSLSocketFactory(sslContext.getSocketFactory());
HostnameVerifier hv = new HostnameVerifier() {
public boolean verify(String string, SSLSession ssls)
{
System.out.println("Warning: URL Host: "+string +
" vs. " + ssls.getPeerHost());
return true;
}
};
HttpsURLConnection.setDefaultHostnameVerifier(hv);
sslSocketFactory = sslContext.getSocketFactory();
System.out.println("SSL Socket Factory is done");
} catch (java.security.NoSuchAlgorithmException e) {
e.printStackTrace(System.out);
throw e;
} catch (java.security.KeyManagementException e) {
e.printStackTrace(System.out);
throw e;
}
}
private final void initializeTrustManager() throws Exception {
// init new TrustManager
trustManager = new TrustManager[] {
new X509TrustManager()
{
public java.security.cert.X509Certificate[]
getAcceptedIssuers() {
System.out.println("InitializeTrustManager:
getAcceptedIssuers:");
return null;
}

public void checkClientTrusted(
java.security.cert.X509Certificate[] certs,
String authType) {
System.out.println("initializeTrustmanager:
checkClientTrusted:" + certs[0]
+ " authTyp:" + authType);
}

public void checkServerTrusted(
java.security.cert.X509Certificate[] certs,
String authType) {
System.out.println("InitializeTrustManager:
checkServerTrusted:"
+ certs[0].getIssuerDN() + " authTyp:" +
authType);

}
public boolean isClientTrusted(X509Certificate[] arg0)
{
return true;
}
public boolean isServerTrusted(X509Certificate[] arg0)
{
return true;
}
}
};
}
public void connectTo()
{
try
{
System.out.println("Initialization of trust Manager");
initializeTrustManager();
System.out.println("Initialization of SSL Context");
initializeSSLContext();
// open a socket to the server
connection =
(SSLSocket)sslSocketFactory.createSocket("192.168.0.120", port);
//connection.setSSLParameters(null)
//connection.startHandshake();
//URL u = new URL("https://192.168.0.120:5000/");
//HttpsURLConnection http = (HttpsURLConnection)
u.openConnection();

//java.security.cert.Certificate[] serverCerts =
connection.getSession().getPeerCertificates();
// open streams for reading and writing
outStream = new PrintWriter(new OutputStreamWriter(
connection.getOutputStream()),true);

inStream = new BufferedReader(new InputStreamReader(
connection.getInputStream()));
}
catch(Exception e)
{
}
}
}

Those program is run from NetBeans directly

Thank you to all for your help
 
Ad

Advertisements

D

Daniele Futtorovic

Dear developers,

I am trying to write some client program which will open port 5000 on
the client side and connect to the computer where is run daemon which
listen on the port 5000.
Those port should be secured over SSL.
I have build up the C++ daemon which listen on that port together with
SSL and when I am writing
command:
openssl s_client -ssl3 -connect 192.168.0.120:9000
then in the log of daemon I can see that connection was establish and
working correctly.
Including server certificate, SSL handshake and Secure Renegotiation

I would like to created some client in Java but there I have some
problems.
When I run Java client application the in the daemon I see message:

24741:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
number:s3_pkt.c:295:

My Java code is:

Those program is run from NetBeans directly

"Wrong version number". Check which version your OpenSSL client is,
check which version of Java you're using. Try updating both of them, to
see if it fixes it. If that doesn't help, are you tied to SSL 3.0? Java
supports TLS out-of-the-box.

Google for "SSL3_GET_RECORD:wrong version number:" did yield a lot of
results.

HTH.
 
D

Daniele Futtorovic

"Wrong version number". Check which version your OpenSSL client is,
check which version of Java you're using. Try updating both of them, to
see if it fixes it. If that doesn't help, are you tied to SSL 3.0? Java
supports TLS out-of-the-box.

Google for "SSL3_GET_RECORD:wrong version number:" did yield a lot of
results.

HTH.

Also, check whether you're using the Sun Provider. Find out the which
class the SSLContext instance you're getting is.
 
S

Stone

"Wrong version number". Check which version your OpenSSL client is,
check which version of Java you're using. Try updating both of them, to
see if it fixes it. If that doesn't help, are you tied to SSL 3.0? Java
supports TLS out-of-the-box.

Google for "SSL3_GET_RECORD:wrong version number:" did yield a lot of
results.

HTH.

I hopen that openssl -version command or similar syntax will show me
what version of openssl is used.
Could you please let me know how I can check in netbeans what version
is used in NetBeans. How I can tied SSL 3.0 with my JAVA. I thought
that it is enought to writedown SSLContext.getInstance("TLSv1") or
SSLContext.getInstance("SSLv3").
 
S

Stone

Also, check whether you're using the Sun Provider. Find out the which
class the SSLContext instance you're getting is.


This I do not understand. I am using java JRE from Sun Java (or
Oracle) pages.
Also JDK is installed on the my computer.
How can I find what SSLContext instace is using?

One thing which I have observed during my tests is:
When my Java class is trying to connect openssl s_server all is
working fine.
When openssl s_client is trying to connect my C++ daemon that all is
working fine as well.
But when my Java class is trying to connect my C++ daemon that it
failed with the error described above.

Thank you for your help.
 
S

Stone

I misunderstood you. I thought you were calling OpenSSL from your C++
daemon, that OpenSSL was actually your daemon. So the problem appears to
be between what your Java program sends and what your C++ daemon
expects, not between what your Java program sends and OpenSSL, as I had
surmised.

One way to check what provider your JRE is using is simply to do:
  SSLContext.getInstance("SSLv3").getClass().getName()
and to print out the result.

I don't know how you can check what whichever C++ library ("s3_pkt.c")
you're using expects, but I think the problem is between those two.

As I mentioned, you might get out of your troubles simply by updating
the libraries you're using (JRE and C++) to the latest versions. You can
also search the web for the error you're getting. Sorry, but that's all
I can currently think of.

The princip of my program should be Java applet has to communicate
with server on the specific port which should be secured over OpenSSL.
Both have to use libssl library.

I have found some articles like:
(for Java)
http://www.exampledepot.com/egs/javax.net.ssl/Server.html
http://stilius.net/java/java_ssl.php

(for C++)
http://www.metalshell.com/source_code/108/OpenSSL_Server_Example.html
http://h71000.www7.hp.com/doc/83final/ba554_90007/ch05s04.html
 
Ad

Advertisements

S

Stone

I misunderstood you. I thought you were calling OpenSSL from your C++
daemon, that OpenSSL was actually your daemon. So the problem appears to
be between what your Java program sends and what your C++ daemon
expects, not between what your Java program sends and OpenSSL, as I had
surmised.

One way to check what provider your JRE is using is simply to do:
  SSLContext.getInstance("SSLv3").getClass().getName()
and to print out the result.

I don't know how you can check what whichever C++ library ("s3_pkt.c")
you're using expects, but I think the problem is between those two.

As I mentioned, you might get out of your troubles simply by updating
the libraries you're using (JRE and C++) to the latest versions. You can
also search the web for the error you're getting. Sorry, but that's all
I can currently think of.

You mentioned:
So the problem appears to
be between what your Java program sends and what your C++ daemon
expects, not between what your Java program sends and OpenSSL, as I had
surmised.

Does it mean that in Java code should be someone encoded message for C+
+ daemon?
Best Regards
Petr
 
S

Stone

I misunderstood you. I thought you were calling OpenSSL from your C++
daemon, that OpenSSL was actually your daemon. So the problem appears to
be between what your Java program sends and what your C++ daemon
expects, not between what your Java program sends and OpenSSL, as I had
surmised.

One way to check what provider your JRE is using is simply to do:
  SSLContext.getInstance("SSLv3").getClass().getName()
and to print out the result.

I don't know how you can check what whichever C++ library ("s3_pkt.c")
you're using expects, but I think the problem is between those two.

As I mentioned, you might get out of your troubles simply by updating
the libraries you're using (JRE and C++) to the latest versions. You can
also search the web for the error you're getting. Sorry, but that's all
I can currently think of.

I have write down to my code your Java code and result of
SSLContext.getInstance("TLS").getClass().getName() is
"javax.net.ssl.SSLContext"

Result is the same for SSLv3.

Best regards
Petr
 
D

Daniele Futtorovic

You mentioned:

Does it mean that in Java code should be someone encoded message for C+
+ daemon?

(Please don't quote signatures)

No, it means that your C++ daemon doesn't understand the SSL version
Java is talking to it with.
I have write down to my code your Java code and result of
SSLContext.getInstance("TLS").getClass().getName() is
"javax.net.ssl.SSLContext"

Sorry, my mistake. You need to have a look at:
SSLContext.getInstance( [protocol] ).getProvider();

If it prints something with "SunJSSE", then you have the default one.
 
S

Stone

You mentioned:
Does it mean that in Java code should be someone encoded message for C+
+ daemon?

(Please don't quote signatures)

No, it means that your C++ daemon doesn't understand the SSL version
Java is talking to it with.
I have write down to my code your Java code and result of
SSLContext.getInstance("TLS").getClass().getName()  is
"javax.net.ssl.SSLContext"

Sorry, my mistake. You need to have a look at:
  SSLContext.getInstance( [protocol] ).getProvider();

If it prints something with "SunJSSE", then you have the default one.

Yes it prints "SunJSSE version 1.6".
It is problem? What should be mentioned here?
Shall I install something different?

I still do not understand where can be a problem?
best regards
Petr
 
L

Lothar Kimmeringer

Stone said:
24741:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
number:s3_pkt.c:295:
[...]
sslContext = SSLContext.getInstance("SSLv3");

I filed a bugreport about two years ago showing that the JSSE is
creating TLSv1-messages in some circumstances but since this falled
within the Oracle-takeover of SUN it seems that it has been ignored.

To find out if this specific bug is biting here, start Wireshark
and listen to the packets being exchanged between your client and
the server. The client-hello message is unencrypted, so it should
be easy to see what version is sent to the server.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
 
Ad

Advertisements

S

Stone

Stone said:
24741:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
number:s3_pkt.c:295:
[...]
            sslContext = SSLContext.getInstance("SSLv3");

I filed a bugreport about two years ago showing that the JSSE is
creating TLSv1-messages in some circumstances but since this falled
within the Oracle-takeover of SUN it seems that it has been ignored.

To find out if this specific bug is biting here, start Wireshark
and listen to the packets being exchanged between your client and
the server. The client-hello message is unencrypted, so it should
be easy to see what version is sent to the server.

Regards, Lothar
--
Lothar Kimmeringer                E-Mail: (e-mail address removed)
               PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
                 questions!

Is it possible to send me that bugreport?
Does it mean that when I will change SSLv3 to TLSv1 as on the Java
side as on the C++ daemon then all will work w/o problems?
Is it possible to make some workaround so that all will work fine?
What in the case that will change JRE from SUN to IBM?

If the provider is SunJSSE as a default one is it possible to exchange
them?
I have made some test so that instead of port 5000 I used to port 443
for detection whether problem is on the applet side (from the
programmer point of view) and all was working OK.

How can I detect whether problem is in the programming language or in
the bugreport?

best regards
Petr
 
L

Lothar Kimmeringer

Stone said:
Stone wrote: [...]

I filed a bugreport about two years ago showing that the JSSE is
creating TLSv1-messages in some circumstances but since this falled
within the Oracle-takeover of SUN it seems that it has been ignored.
Is it possible to send me that bugreport?

In short: If a session is reused, TLSv1 will be used for client
hello instead of SSLv3. Most servers can cope with that since
TLSv1 is constructed the same way SSLv3 is but some servers are
too strict and expect a specific header-size.
Does it mean that when I will change SSLv3 to TLSv1 as on the Java
side as on the C++ daemon then all will work w/o problems?

Depends on two things: The client really sends TLSv1 and the
server has no other problem and only returns a wrong error-message.
Is it possible to make some workaround so that all will work fine?

Disable session-reusage (which is not possible with the API
of the JSSE...)
What in the case that will change JRE from SUN to IBM?

I don't know, I haven't tested IBM JVM at that point of time but
if the JSSE-provider is the same (which I doubt) you should have
the same effect.
If the provider is SunJSSE as a default one is it possible to exchange
them?

I'm not sure and you shouldn't start introducing dependencies into
your Java-program (which is supposed to work without system-de-
pendencies).
I have made some test so that instead of port 5000 I used to port 443
for detection whether problem is on the applet side (from the
programmer point of view) and all was working OK.

Hm, that shouldn't be the case but who knows.
How can I detect whether problem is in the programming language or in
the bugreport?

As I said: Use Wireshark to see the actual communication between
client and server and check if TLSv1 is used instead of SSLv3.


Regards, Lothar
--
Lothar Kimmeringer E-Mail: (e-mail address removed)
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!
 
S

Stone

Disable SSLv2ClientHello in your Java client. Remove it from the list of
enabled protocols on the socket.

Hello Esmond,

thanks for you hint.
When I removed SSLv2Client than all works fine.

best regards
Petr
 
S

Stone

Hello Esmond,

thanks for you hint.
When I removed SSLv2Client than all works fine.

best regards
Petr

Connection was established successfully but when I am writting
something from C++ daemon to Java applet that I see those message:
25280:error:140940F6:SSL routines:SSL3_READ_BYTES:unknown alert
type:s3_pkt.c:1063:

in the C++ daemon after function accept is written:
result=accept(listenSocket,...,...);
setsockopt(result,SOL_SOCKET,SO_KEEPALIVE,...,...);
ssl = SSL_new(ctx);
retval = SSL_set_fd((SSL*)ssl,result);
SSL_set_accept_state(ssl);
SSL_renegotiate((SSL*)ssl);
SSL_accept((SSL*)ssl);
char * message = "HELLO WORLD";
SSL_write(ssl,message,sizeof(message));

is that something wrong?
Unfortunatelly I am not able to send any data from C++ to Java client?

Any hint?

best regards
Petr
 
Ad

Advertisements

E

Esmond Pitt

Connection was established successfully

Lucky guess on my part.
but when I am writting
something from C++ daemon to Java applet that I see those message:
25280:error:140940F6:SSL routines:SSL3_READ_BYTES:unknown alert
type:s3_pkt.c:1063:

Can you run the Java client with -Djavax.net.debug=ssl,handshake,record
and post the output here? It should show what alert is being generated.
SSL_write(ssl,message,sizeof(message));

Is your Java client really going to understand a null-terminated 'C'
string? You need to sort out this part of your protocol: in general
that's not going to work unless you can completely avoid null characters
inside your data.
 
S

Stone

Lucky guess on my part.


Can you run the Java client with -Djavax.net.debug=ssl,handshake,record
and post the output here? It should show what alert is being generated.


Is your Java client really going to understand a null-terminated 'C'
string? You need to sort out this part of your protocol: in general
that's not going to work unless you can completely avoid null characters
inside your data.

Thank you to all. All is working properly.

But may be you have a some idea where can be a problem with that
situation.

Sometimes I am receiving following fatal error:
javax.net.ssl.SSLException: Received fatal alert: unexpected_message
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown
Source)
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown
Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(Unknown
Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown
Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(Unknown
Source)
at com.sun.net.ssl.internal.ssl.AppInputStream.read(Unknown Source)

First message send to the server is OK and I am receiving proper
answer but afterwards when I am trying to send next message than the
follwoing error occurs.
Server is run in KVM (Kernel-based Virtual Machine).

What type of problem is this?
For the wireshark I saw in Protocol TLSv1:
- ClientHello
- ServerHello, Change Cipher Spec, Finished
- Application Data
- Alert (Level: Fatal, Description: Unexpected Message)

Best regards
Petr
 
Ad

Advertisements

S

Stone

Can you do what I asked above?

Here is the output:


main, READ: TLSv1 Handshake, length = 4
*** ServerHelloDone
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1
main, WRITE: TLSv1 Handshake, length = 134
SESSION KEYGEN:
PreMaster Secret:
0000: 03 01 8F 2E E0 03 2C EE 58 8D 1B 88 BB F7 30 9B ......,.X.....
0.
0010: 60 84 6B EC C8 F2 86 D7 13 CB 84 CA 10 8B 84 50
`.k............P
0020: 7E BB DE 1B 7A 1D 59 DE 65 A8 41 C1 D4 9F EE
1A ....z.Y.e.A.....
CONNECTION KEYGEN:
Client Nonce:
0000: 4D D6 2A D7 80 C4 53 B2 32 3E 86 AE A8 9B D3 11 M.*...S.
2>......
0010: 19 DD AB 83 0F 31 33 4E D9 07 ED CB BA 23 66 5F .....
13N.....#f_
Server Nonce:
0000: 4D D6 2E 7E 3B FF A3 24 C3 01 8D 40 30 A9 70 3A M...;..
[email protected]:
0010: D2 D3 34 FA FE EE E7 DB 33 CE 18 8F FC FA A2 D3 ..
4.....3.......
Master Secret:
0000: 02 14 E4 13 FE B6 05 7E 4C EA F7 C9 6F DC 46
8B ........L...o.F.
0010: E8 96 E2 3A B8 9A 01 6A 02 B4 DC 0D 39 77 2A AB ...:...j....
9w*.
0020: 3C AE CD 0A 35 1E 5A 5D EC 55 08 A2 3E D9 2A 7C <...
5.Z].U..>.*.
Client MAC write Secret:
0000: 6B E9 D3 2A 9B 99 D1 85 1F 8B AE 21 E3 92 9D 83
k..*.......!....
Server MAC write Secret:
0000: FA E1 F8 A2 BE 3A 9F EB E0 1D D1 90 FE EC 85
CB .....:..........
Client write key:
0000: EA 34 4D 65 92 99 8F 46 79 B4 D1 DA 3B B7 93 26 .
4Me...Fy...;..&
Server write key:
0000: 04 91 71 8D 6A 28 3B BD EA 21 01 6E 70 FB 06
EE ..q.j(;..!.np...
.... no IV used for this cipher
main, WRITE: TLSv1 Change Cipher Spec, length = 1
*** Finished
verify_data: { 194, 94, 110, 184, 146, 84, 139, 23, 128, 30, 172,
154 }
***
main, WRITE: TLSv1 Handshake, length = 32
main, READ: TLSv1 Change Cipher Spec, length = 1
main, READ: TLSv1 Handshake, length = 32
*** Finished
verify_data: { 221, 84, 99, 182, 94, 229, 245, 49, 239, 9, 242, 116 }
***
%% Cached client session: [Session-1, SSL_RSA_WITH_RC4_128_MD5]
Getting session was done
Peer host is 192.168.0.120
Cipher is SSL_RSA_WITH_RC4_128_MD5
Protocol is TLSv1
Socket class: class com.sun.net.ssl.internal.ssl.SSLSocketImpl
Remote address = /192.168.0.120
Remote port = 5000
Local socket address = /10.7.254.22:2184
Local address = /192.168.0.130
Local port = 2184
Need client authentication = false
Cipher suite = SSL_RSA_WITH_RC4_128_MD5
Protocol = TLSv1
main, READ: TLSv1 Handshake, length = 20
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: false
Is secure renegotiation: true
*** HelloRequest (empty)
%% Client cached [Session-1, SSL_RSA_WITH_RC4_128_MD5]
%% Try resuming [Session-1, SSL_RSA_WITH_RC4_128_MD5] from port 2184
*** ClientHello, TLSv1
RandomCookie: GMT: 1289103832 bytes = { 65, 48, 233, 162, 111, 170,
145, 44, 19
9, 239, 216, 52, 135, 235, 207, 100, 46, 51, 207, 42, 143, 130, 172,
180, 10, 84
, 41, 182 }
Session ID: {250, 122, 71, 89, 118, 196, 255, 44, 117, 119, 69, 73,
223, 161, 1
26, 19, 49, 161, 129, 40, 140, 144, 141, 116, 217, 98, 244, 232, 131,
214, 79, 1
42}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA,
TLS_RSA_WITH
_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_128_CBC
_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_
DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA,
SSL_DHE_RSA_WITH_DES_CBC_SH
A, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5,
SSL_RSA_EXPORT_
WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA,
SSL_DHE_DSS_EXPORT_WI
TH_DES40_CBC_SHA]
Compression Methods: { 0 }
Extension renegotiation_info, renegotiated_connection: c2:5e:
6e:b8:92:54:8b:17:8
0:1e:ac:9a
***
main, WRITE: TLSv1 Handshake, length = 140
main, READ: TLSv1 Application Data, length = 106
HELLO_SSL_SERVER_IS_HERE
main, WRITE: TLSv1 Application Data, length = 74
main, READ: TLSv1 Handshake, length = 121
*** ServerHello, TLSv1
RandomCookie: GMT: 1289105023 bytes = { 255, 208, 20, 94, 83, 1, 175,
155, 28,
235, 171, 32, 185, 187, 240, 129, 197, 41, 89, 188, 75, 176, 55, 176,
247, 226,
12, 57 }
Session ID: {250, 122, 71, 89, 118, 196, 255, 44, 117, 119, 69, 73,
223, 161, 1
26, 19, 49, 161, 129, 40, 140, 144, 141, 116, 217, 98, 244, 232, 131,
214, 79, 1
42}
Cipher Suite: SSL_RSA_WITH_RC4_128_MD5
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: c2:5e:
6e:b8:92:54:8b:17:8
0:1e:ac:9a:dd:54:63:b6:5e:e5:f5:31:ef:09:f2:74
***
CONNECTION KEYGEN:
Client Nonce:
0000: 4D D6 2A D8 41 30 E9 A2 6F AA 91 2C C7 EF D8 34
M.*.A0..o..,...4
0010: 87 EB CF 64 2E 33 CF 2A 8F 82 AC B4 0A 54 29 B6 ...d.
3.*.....T).
Server Nonce:
0000: 4D D6 2E 7F FF D0 14 5E 53 01 AF 9B 1C EB AB 20
M......^S......
0010: B9 BB F0 81 C5 29 59 BC 4B B0 37 B0 F7 E2 0C 39 .....)Y.K.
7....9
Master Secret:
0000: 02 14 E4 13 FE B6 05 7E 4C EA F7 C9 6F DC 46
8B ........L...o.F.
0010: E8 96 E2 3A B8 9A 01 6A 02 B4 DC 0D 39 77 2A AB ...:...j....
9w*.
0020: 3C AE CD 0A 35 1E 5A 5D EC 55 08 A2 3E D9 2A 7C <...
5.Z].U..>.*.
Client MAC write Secret:
0000: C0 8D 44 8C EB 61 E5 F1 E6 3D D2 A9 BC 2F 35 4F ..D..a...=.../
5O
Server MAC write Secret:
0000: 9B 82 E2 D4 46 5D 27 87 28 5A B4 29 B9 89 EE 30 ....F]'.
(Z.)...0
Client write key:
0000: 17 3C 40 19 92 BE A2 39 9C E4 DB 21 4F 73 1F 84 .<@....9...!
Os..
Server write key:
0000: 4B 7A 61 1E D2 A0 77 64 E5 F4 CF C6 5A 1C 7C 4A
Kza...wd....Z..J
.... no IV used for this cipher
%% Server resumed [Session-1, SSL_RSA_WITH_RC4_128_MD5]
main, READ: TLSv1 Change Cipher Spec, length = 17
main, READ: TLSv1 Handshake, length = 32
*** Finished
verify_data: { 97, 230, 102, 11, 191, 75, 26, 119, 46, 96, 184, 61 }
***
main, WRITE: TLSv1 Change Cipher Spec, length = 17
*** Finished
verify_data: { 202, 55, 36, 163, 185, 216, 10, 77, 62, 152, 71, 69 }
***
main, WRITE: TLSv1 Handshake, length = 32
main, READ: TLSv1 Alert, length = 18
main, RECV TLSv1 ALERT: fatal, unexpected_message
%% Invalidated: [Session-1, SSL_RSA_WITH_RC4_128_MD5]
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLException: Received fatal
alert: unex
pected_message
 
Ad

Advertisements


Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top