Does SSL works at all in classpath version 0.98 ???

[alk.shr]

i am not able to run my web application on HTTPS port (secure port through SSL) although it run fine on normal HTTP port.

Environment used to run web application is as-
        GNU Classpath ver 0.98
        JamVm ver 1.53
        Jetty 1.6.8
        Linux Debian based
        IE and mozilla browser
        keystore- type GKR
        Crypto and SSL implementation- in GNU Classpath ver 0.98

Basically i got multiple issues while trying to run application on HTTPS ports, some of them i was able to resolve after debugging GNU classpath source code. Problems faced by me are described below-

Problem # 1
----------------------
-Server socket listening on HTTPS port (8443 in our case) not responding to requests coming from browser.

After analysis, i have found that SSL server socket has been listening on HTTPS port 8443 and accepting initial request coming from browser for connection and creating SSL client socket in response. but after this there is no response from SSL client socket created earlier. It seem that no input stream is open to the client socket to read data coming from browser.


I think above issue is coming due to some bug in the SSLSocketImpl class under gnu.javax.net.ssl.provider package. In constructor of this class,a new Socket is created (i do not know why??) which is stored in underlyingSocket variable of SSLSocketImpl class. All requests of read and write is then delegated to member variable underlyingSocket. I think after copying new socket reference to underlyingSocket variable, this socket(underlyingSocket) is not connected to same native socket which is created in response of initial request from browser therefore SSL client socket is not responding to the browser request.

I have fixed this issue by not setting underlyingSocket variable to new Socket and adding check for null at all places where underlyingSocket is refereed. I have diverted all calls on underlyingSocket to super class of SSLSocketImpl.

Please confirm whether is this a bug in the SSLSocketImpl class or have i done something  wrong?

Problem # 2
-----------------------
SSL handshake starts working but IllegalArgumentException exception is coming from setLength API in Record class under gnu.javax.net.ssl.provider package.


i think length check (between 0 and 16384 (2^14)) on SSL record is not correct. As per SSL RFC, length of final SSL record after encryption and compression may exceed by 2048 bytes.

I have fixed this issue by changing maximum length to 17408.

Please confirm is this the bug in the Record class?

Problem # 3
------------------------
In decrypt API of InputSecurityParameters  class under gnu.javax.net.ssl.provider package, sometimes length calculated for padding in case of block cipher is more then size of SSL record/fragment resulting in  IllegalArgumentException.

I have seen this issue only with Internet explorer browser. At line # 173 in this class, IllegalArgumentException comes on calling positing API of ByteBuffer due to passing negative index.

       
                                else if (record.version().compareTo(ProtocolVersion.TLS_1) >= 0)
                                                  {
                                                        // In TLSv1 and later, the padding must be `padlen' copies of the
                                                        // value `padlen'.
                                                        byte[] pad = new byte[padlen];
                                                       
                                                        //IllegalArgumentException comes at below line
                                                        ((ByteBuffer) fragment.duplicate().position(record.length() - padlen - 1)).get(pad);
                                                       
                                                       
                                                        for (int i = 0; i < pad.length; i++)
                                                          if ((pad[i] & 0xFF) != padlen)
                                                                badPadding = true;
                                                        if (Debug.DEBUG)
                                                          logger.logv(Component.SSL_RECORD_LAYER, "TLSv1.x padding\n{0}",
                                                                                  new ByteArray(pad));
                                          }
                                         
                                         
To resolve this issue, time being i have put safe check of positive index before the line where exception is coming.




Now even after resolving all above mentioned issues, sometimes bad certificate or not valid signature error is coming on browser on opening pages using HTTPS.

I have to provide HTTPS support and now i am really stuck. please guide me in resolving SSL related issues.

[Audrius Meskauskas]

alk.shr wrote:
> i am not able to run my web application on HTTPS port (secure port through
> SSL) although it run fine on normal HTTP port.
This is a bug that must be verified. I add this to Bugzilla.

See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40774 now. You can also
register and then be notified about changes in the bug.

Thanks for so comprehensive report.

Audrius

[Robert Dodier]

For the record, I've also tried SSL with Classpath 0.98 + JamVM 1.5.2
 + ARM cpu. The observed behavior was that HTTPS connections
caused the VM to allocate much more memory than with HTTP,
until the VM failed with a memory allocation error.

Sorry that this is very vague, however, I don't have any more
specific info. But perhaps if we start pooling anecdotes we
can get started debugging it.

FWIW

Robert Dodier

[gnu_andrew]

2009/7/16 Audrius Meskauskas <audriusa@...>:

> alk.shr wrote:
>> i am not able to run my web application on HTTPS port (secure port through
>> SSL) although it run fine on normal HTTP port.
> This is a bug that must be verified. I add this to Bugzilla.
>
> See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40774 now. You can also
> register and then be notified about changes in the bug.
>
> Thanks for so comprehensive report.
>
> Audrius
>
>
>
>

Test cases for this issues would also help.  I don't see how these
failures can be replicated from the information given.
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

[alk.shr]

Thanks for reply and filing bug to Bugzilla.

Please tell me what extra information do you requires to test reported issues in the SSL? If requires, i can send you all source files of classpath modified by me.

one more thing, i got one more issue.In SSL implementation of classpath, Full SSL handshake (including secret key generation ) is  happening on selecting every link (HTTP GET) from web application. This is not the case with SUN JRE where SSL handshake happen in beginning and after SSL session time out.

Again i suspect bug in the SSL implementation because it creates new SSL session for every GET request instead of sharing previous session.

gnu_andrew wrote:

2009/7/16 Audrius Meskauskas <[e-mail]>:
> alk.shr wrote:
>> i am not able to run my web application on HTTPS port (secure port through
>> SSL) although it run fine on normal HTTP port.
> This is a bug that must be verified. I add this to Bugzilla.
>
> See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40774 now. You can also
> register and then be notified about changes in the bug.
>
> Thanks for so comprehensive report.
>
> Audrius
>
>
>
>

Test cases for this issues would also help.  I don't see how these
failures can be replicated from the information given.
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8

[Andrew Haley]

On 07/20/2009 08:28 AM, alk.shr wrote:

> Thanks for reply and filing bug to Bugzilla.
>
> Please tell me what extra information do you requires to test reported
> issues in the SSL? If requires, i can send you all source files of classpath
> modified by me.
>
> one more thing, i got one more issue.In SSL implementation of classpath,
> Full SSL handshake (including secret key generation ) is  happening on
> selecting every link (HTTP GET) from web application. This is not the case
> with SUN JRE where SSL handshake happen in beginning and after SSL session
> time out.
>
> Again i suspect bug in the SSL implementation because it creates new SSL
> session for every GET request instead of sharing previous session.

Quite possibly.  But if you want the best chance of getting the bug
fixed, create a small test case that demonstrates the problem.

Andrew.

[fubi]

Hi, i'm having similar issues when trying to run my application on https port. My environment is a litle different and more difficult to replicate, but i think that the problem is the same.
I'm using JamVM 1.5.3 with GNU Classpath 0.98, running on openwrt Kamikaze 8.09 (kernel 2.6). The jetty server is Jetty 6.1.16 (as bundled version) since i'm running it on an OSGi Framework. Again as for setting up a simple http server i found no problems, but when i try to set up the https the http seems to be frozen and the https is not accessible.
I belive that my configuration of the jetty server is correct, and also im using an valid gkr keystore generated with gkeytool.
The problem with http is due to the https, because the server never starts on port 8443 (used netstat to see if the port are in listen state), but the http starts on 8080. The log level that i can get from the framework or the bundle containing the jetty server is almost zero, still i've tryed to make some changes in the source as you pointed, but with no success even on starting the https server.

Is it possible for you to provide the source of the classes that you have changed to successfully start the server on the 8443 port?

--------
fubi


alk.shr wrote:

alk.shr wrote:

i am not able to run my web application on HTTPS port (secure port through SSL) although it run fine on normal HTTP port.

Environment used to run web application is as-
        GNU Classpath ver 0.98
        JamVm ver 1.53
        Jetty 1.6.8
        Linux Debian based
        IE and mozilla browser
        keystore- type GKR
        Crypto and SSL implementation- in GNU Classpath ver 0.98

[fubi]

Any development on the original issue?