SSL client program

Discussion in 'Java' started by Stone, May 13, 2011.

  1. Stone

    Stone Guest

    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
     
    Stone, May 13, 2011
    #1
    1. Advertising

  2. On 13/05/2011 10:09, Stone allegedly wrote:
    > 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:


    <snip />

    > 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.

    --
    DF.
    An escaped convict once said to me:
    "Alcatraz is the place to be"
     
    Daniele Futtorovic, May 13, 2011
    #2
    1. Advertising

  3. On 13/05/2011 18:39, Daniele Futtorovic allegedly wrote:
    > On 13/05/2011 10:09, Stone allegedly wrote:
    >> 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:

    >
    > <snip />
    >
    >> 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.
    >


    Also, check whether you're using the Sun Provider. Find out the which
    class the SSLContext instance you're getting is.
     
    Daniele Futtorovic, May 13, 2011
    #3
  4. Stone

    Stone Guest

    On 13 kvÄ›, 18:39, Daniele Futtorovic <da.futt.n...@laposte-dot-
    net.invalid> wrote:
    > On 13/05/2011 10:09, Stone allegedly wrote:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > 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:

    >
    > <snip />
    >
    > > 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.
    >
    > --
    > DF.
    > An escaped convict once said to me:
    > "Alcatraz is the place to be"


    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").
     
    Stone, May 14, 2011
    #4
  5. Stone

    Stone Guest

    On 13 kvÄ›, 18:57, Daniele Futtorovic <da.futt.n...@laposte-dot-
    net.invalid> wrote:
    > On 13/05/2011 18:39, Daniele Futtorovic allegedly wrote:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > On 13/05/2011 10:09, Stone allegedly wrote:
    > >> 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:

    >
    > > <snip />

    >
    > >> 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.

    >
    > 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.
     
    Stone, May 14, 2011
    #5
  6. Stone

    Stone Guest

    On 14 kvÄ›, 17:34, Daniele Futtorovic <da.futt.n...@laposte-dot-
    net.invalid> wrote:
    > On 14/05/2011 10:54, Stone allegedly wrote:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > On 13 kvÄ›, 18:57, Daniele Futtorovic<da.futt.n...@laposte-dot-
    > > net.invalid>  wrote:
    > >> On 13/05/2011 18:39, Daniele Futtorovic allegedly wrote:

    >
    > >>> On 13/05/2011 10:09, Stone allegedly wrote:
    > >>>> 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:

    >
    > >>> <snip />

    >
    > >>>> 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.

    >
    > >> 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.

    >
    > 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.
    >
    > --
    > DF.
    > An escaped convict once said to me:
    > "Alcatraz is the place to be"


    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
     
    Stone, May 14, 2011
    #6
  7. Stone

    Stone Guest

    On 14 kvÄ›, 17:34, Daniele Futtorovic <da.futt.n...@laposte-dot-
    net.invalid> wrote:
    > On 14/05/2011 10:54, Stone allegedly wrote:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > On 13 kvÄ›, 18:57, Daniele Futtorovic<da.futt.n...@laposte-dot-
    > > net.invalid>  wrote:
    > >> On 13/05/2011 18:39, Daniele Futtorovic allegedly wrote:

    >
    > >>> On 13/05/2011 10:09, Stone allegedly wrote:
    > >>>> 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:

    >
    > >>> <snip />

    >
    > >>>> 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.

    >
    > >> 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.

    >
    > 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.
    >
    > --
    > DF.
    > An escaped convict once said to me:
    > "Alcatraz is the place to be"


    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
     
    Stone, May 14, 2011
    #7
  8. Stone

    Stone Guest

    On May 14, 5:34 pm, Daniele Futtorovic <da.futt.n...@laposte-dot-
    net.invalid> wrote:
    > On 14/05/2011 10:54, Stone allegedly wrote:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > On 13 kvÄ›, 18:57, Daniele Futtorovic<da.futt.n...@laposte-dot-
    > > net.invalid>  wrote:
    > >> On 13/05/2011 18:39, Daniele Futtorovic allegedly wrote:

    >
    > >>> On 13/05/2011 10:09, Stone allegedly wrote:
    > >>>> 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:

    >
    > >>> <snip />

    >
    > >>>> 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.

    >
    > >> 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.

    >
    > 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.
    >
    > --
    > DF.
    > An escaped convict once said to me:
    > "Alcatraz is the place to be"


    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
     
    Stone, May 14, 2011
    #8
  9. On 14/05/2011 18:48, Stone allegedly wrote:
    > 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?


    (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.

    --
    DF.
    An escaped convict once said to me:
    "Alcatraz is the place to be"
     
    Daniele Futtorovic, May 14, 2011
    #9
  10. Stone

    Stone Guest

    On 14 kvÄ›, 21:23, Daniele Futtorovic <da.futt.n...@laposte-dot-
    net.invalid> wrote:
    > On 14/05/2011 18:48, Stone allegedly wrote:
    >
    > > 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?

    >
    > (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.
    >
    > --
    > DF.
    > An escaped convict once said to me:
    > "Alcatraz is the place to be"


    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
     
    Stone, May 14, 2011
    #10
  11. Stone wrote:

    > 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:
    PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

    Always remember: The answer is forty-two, there can only be wrong
    questions!
     
    Lothar Kimmeringer, May 15, 2011
    #11
  12. Stone

    Stone Guest

    On May 15, 1:52 pm, Lothar Kimmeringer <>
    wrote:
    > Stone wrote:
    > > 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:
    >                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
     
    Stone, May 15, 2011
    #12
  13. Stone wrote:

    > On May 15, 1:52 pm, Lothar Kimmeringer <>
    > wrote:
    >> 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:
    PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

    Always remember: The answer is forty-two, there can only be wrong
    questions!
     
    Lothar Kimmeringer, May 16, 2011
    #13
  14. Stone

    Esmond Pitt Guest

    On 14/05/2011 6:54 PM, Stone wrote:
    > SSL3_GET_RECORD:wrong version number


    Disable SSLv2ClientHello in your Java client. Remove it from the list of
    enabled protocols on the socket.
     
    Esmond Pitt, May 16, 2011
    #14
  15. Stone

    Stone Guest

    On May 16, 8:54 am, Esmond Pitt <> wrote:
    > On 14/05/2011 6:54 PM, Stone wrote:
    >
    > > SSL3_GET_RECORD:wrong version number

    >
    > 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
     
    Stone, May 16, 2011
    #15
  16. Stone

    Stone Guest

    On May 16, 12:08 pm, Stone <> wrote:
    > On May 16, 8:54 am, Esmond Pitt <> wrote:
    >
    > > On 14/05/2011 6:54 PM, Stone wrote:

    >
    > > > SSL3_GET_RECORD:wrong version number

    >
    > > 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


    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
     
    Stone, May 16, 2011
    #16
  17. Stone

    Esmond Pitt Guest

    On 16/05/2011 10:22 PM, Stone wrote:
    > 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.
     
    Esmond Pitt, May 17, 2011
    #17
  18. Stone

    Stone Guest

    On May 17, 1:33 am, Esmond Pitt <> wrote:
    > On 16/05/2011 10:22 PM, Stone wrote:
    >
    > > 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.


    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
     
    Stone, May 19, 2011
    #18
  19. Stone

    Esmond Pitt Guest

    On 19/05/2011 6:46 PM, Stone wrote:
    > On May 17, 1:33 am, Esmond Pitt<> wrote:
    >> 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.

    >
    > What type of problem is this?


    Can you do what I asked above?
     
    Esmond Pitt, May 20, 2011
    #19
  20. Stone

    Stone Guest

    On May 20, 6:15 am, Esmond Pitt <> wrote:
    > On 19/05/2011 6:46 PM, Stone wrote:
    >
    > > On May 17, 1:33 am, Esmond Pitt<>  wrote:
    > >> 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..

    >
    > > What type of problem is this?

    >
    > 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...;..
    $:
    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
     
    Stone, May 20, 2011
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Joe Wong
    Replies:
    2
    Views:
    4,124
  2. Krzysztof Pa¼
    Replies:
    1
    Views:
    680
    Krzysztof Pa¼
    Sep 26, 2003
  3. News123
    Replies:
    9
    Views:
    3,094
    vilas
    Feb 15, 2012
  4. Replies:
    1
    Views:
    266
    Brian Candler
    May 16, 2007
  5. Replies:
    1
    Views:
    284
Loading...

Share This Page