Re: [classlib][xnet] Problem connecting using SSLSocketImpl

[Alexander Kleymenov]

Hi Gerald,

I'm very happy to hear this issue was fixed.
Thank you for your participation in its resolution!

With my latest patch supplied with HARMONY-2029 JIRA report you can
use Harmony VM and JSSE to work with PKCS12 stores.
To adapt your client code for Harmony you should convert JKS trust
store to BKS type (or generate new BKS one), and rewrite the following
lines of your code:

   KeyManagerFactory kmf = KeyManagerFactory.getInstance(
   KeyManagerFactory.getDefaultAlgorithm());

   . . .

   TrustManagerFactory tmf = TrustManagerFactory.getInstance(
   TrustManagerFactory.getDefaultAlgorithm());


Please feel free to ask if you have any problems with it.

Thank You,
Alexander Kleymenov


On 10/26/06, Gerald Jerome [EMAIL PROTECTED] wrote:

Hi Alexander,

Great job!  This latest patch appears to have fixed the connection issue
with SSLSocketImpl and I have started testing renegotiation with our host.
Everything appears to be working as expected with no errors.  Thanks for
hanging in there and getting this fixed.

Regards,
Gerald Jerome
Vnet 262-2375

Re: [classlib][xnet] Problem connecting using SSLSocketImpl

[Boris Kuznetsov]

Thanks for catching.

Updated provider patch and patch for test are attached to H-1937

Thanks,
Boris


On 10/27/06, Tim Ellison [EMAIL PROTECTED] wrote:

Boris Kuznetsov wrote:
 H-1937 contains the latest patch, but we have no regression test yet.

The patch causes a failure in existing tests:

incorrect out data length expected:2 but was:0

junit.framework.AssertionFailedError: incorrect out data length
expected:2 but was:0 at
org.apache.harmony.xnet.provider.jsse.CertificateVerifyTest.testCertificateVerify(CertificateVerifyTest.java:51)
at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)

Regards,
Tim

--

Tim Ellison ([EMAIL PROTECTED])





--
Best regards,
Boris Kuznetsov
Intel Middleware Products Division

Re: [classlib][xnet] Problem connecting using SSLSocketImpl

[Tim Ellison]

Alexander Kleymenov wrote:
 Hi Gerald,
 
 The problem was with CertificateRequest message – it was made with
 incorrect length of certificate_authorities vector. Please, try
 attached patch. Before applying the patch please revert all previously
 patched files to their initial state:
 
 %Harmony_WS_Root% svn revert
 modules/x-net/src/main/java/org/apache/harmony/xnet/provider/jsse
 
 Thank you for your assistance,
 Alexander Kleymenov

Is this the patch attached to HARMONY-1937?  If so do you have a
regression test for it?  I'd like to apply the fix.

Gerald: does it resolve the problem you had?

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])

Re: [classlib][xnet] Problem connecting using SSLSocketImpl

[Boris Kuznetsov]

H-1937 contains the latest patch, but we have no regression test yet.

Thanks,
Boris

On 10/26/06, Tim Ellison [EMAIL PROTECTED] wrote:

Alexander Kleymenov wrote:
 Hi Gerald,

 The problem was with CertificateRequest message – it was made with
 incorrect length of certificate_authorities vector. Please, try
 attached patch. Before applying the patch please revert all previously
 patched files to their initial state:

 %Harmony_WS_Root% svn revert
 modules/x-net/src/main/java/org/apache/harmony/xnet/provider/jsse

 Thank you for your assistance,
 Alexander Kleymenov

Is this the patch attached to HARMONY-1937?  If so do you have a
regression test for it?  I'd like to apply the fix.

Gerald: does it resolve the problem you had?

Regards,
Tim

--

Tim Ellison ([EMAIL PROTECTED])





--
Best regards,
Boris Kuznetsov
Intel Middleware Products Division

Re: [classlib][xnet] Problem connecting using SSLSocketImpl

[Tim Ellison]

Boris Kuznetsov wrote:
 H-1937 contains the latest patch, but we have no regression test yet.

The patch causes a failure in existing tests:

incorrect out data length expected:2 but was:0

junit.framework.AssertionFailedError: incorrect out data length
expected:2 but was:0 at
org.apache.harmony.xnet.provider.jsse.CertificateVerifyTest.testCertificateVerify(CertificateVerifyTest.java:51)
at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])

Re: [classlib][xnet] Problem connecting using SSLSocketImpl

[Alexander Kleymenov]

Hi Gerald,

The problem was with CertificateRequest message – it was made with
incorrect length of certificate_authorities vector. Please, try
attached patch. Before applying the patch please revert all previously
patched files to their initial state:

%Harmony_WS_Root% svn revert
modules/x-net/src/main/java/org/apache/harmony/xnet/provider/jsse

Thank you for your assistance,
Alexander Kleymenov


On 10/24/06, Gerald Jerome [EMAIL PROTECTED] wrote:

Hello Alexander,

Unfortunately, I'm still getting the decode_error after making the changes
referenced in patch3.txt.  I've attached a .tar file to this reply so you
can verify I made the appropriate changes (.zip files will not go through
our email server).  Below is the debug output I receive:
socket[main] SSLSocketImpl: CLIENT
socket[main] SSLSocketImpl.startHandshake
socket[main] SSLSocketImpl: HS status: NEED_WRAP NEED_WRAP
record[main] SSLRecordProtocol.wrap: TLSPlaintext.fragment[67]:
 01 00 00 3F 03 01 16 16 16 16 C9 61 E8 E5 AF C5
 5C 6E 8A C9 68 77 9D 47 46 66 CA 8C D2 4B FD 75
 F3 96 78 AA FE 3E 00 00 18 00 04 00 05 00 0A 00
 16 00 13 00 09 00 15 00 12 00 03 00 08 00 14 00
 11 01 00
socket[main] SSLSocketImpl: HS status: NEED_UNWRAP NEED_UNWRAP
record[main] SSLRecordProtocol.unwrap: BEGIN [
record[main] Got the message of type: 22
record[main] TLSCiphertext.fragment[74]: ...
 02 00 00 46 03 01 45 3D 15 1B CF 40 57 BF 9C 29
 6A 8C 19 DA A2 12 2B 26 B1 91 27 EB 82 85 FE FE
 CF E1 DD 04 27 F7 20 ED 32 80 1B BA 25 B3 64 24
 0E 7C C0 9E 34 AC 0D 8F 41 78 0D 04 FE 96 D6 1D
 2F 03 67 C6 44 B5 AF 00 04 00
record[main] SSLRecordProtocol:unwrap ] END, type: 22
socket[main] SSLSocketImpl: HS status: NEED_UNWRAP NEED_UNWRAP
record[main] SSLRecordProtocol.unwrap: BEGIN [
record[main] Got the message of type: 22
record[main] TLSCiphertext.fragment[2235]: ...
 0B 00 08 B7 00 08 B4 00 05 7B 30 82 05 77 30 82
 05 21 A0 03 02 01 02 02 0A 27 34 7A FD 00 01 00
 00 09 FA 30 0D 06 09 2A 86 48 86 F7 0D 01 01 05
 05 00 30 81 99 31 20 30 1E 06 09 2A 86 48 86 F7
 0D 01 09 01 16 11 63 65 72 74 2D 72 65 71 40 77
 63 6F 6D 2E 63 6F 6D 31 0B 30 09 06 03 55 04 06
 13 02 55 53 31 0B 30 09 06 03 55 04 08 13 02 43
 4F 31 19 30 17 06 03 55 04 07 13 10 43 6F 6C 6F
 72 61 64 6F 20 53 70 72 69 6E 67 73 31 0C 30 0A
 06 03 55 04 0A 13 03 4D 43 49 31 0C 30 0A 06 03
 55 04 0B 13 03 4E 41 53 31 24 30 22 06 03 55 04
 03 13 1B 4D 43 49 20 54 65 73 74 20 61 6E 64 20
 44 65 76 65 6C 6F 70 6D 65 6E 74 20 43 41 30 1E
 17 0D 30 36 30 34 32 31 31 36 33 35 32 32 5A 17
 0D 31 31 30 34 32 31 31 36 34 35 32 32 5A 30 81
 84 31 23 30 21 06 09 2A 86 48 86 F7 0D 01 09 01
 16 14 6D 61 63 69 65 6A 2E 6E 6F 77 61 6B 40 6D
 63 69 2E 63 6F 6D 31 0B 30 09 06 03 55 04 06 13
 02 55 53 31 0B 30 09 06 03 55 04 08 13 02 4E 59
 31 12 30 10 06 03 55 04 07 13 09 52 79 65 20 42
 72 6F 6F 6B 31 0C 30 0A 06 03 55 04 0A 13 03 4D
 43 49 31 0B 30 09 06 03 55 04 0B 13 02 49 54 31
 14 30 12 06 03 55 04 03 13 0B 53 61 66 65 20 53
 65 72 76 65 72 30 82 01 22 30 0D 06 09 2A 86 48
 86 F7 0D 01 01 01 05 00 03 82 01 0F 00 30 82 01
 0A 02 82 01 01 00 D0 99 17 A4 C3 84 6D 81 B3 6C
 9B A3 82 F4 26 6D 84 6E 1C 4E ED 5D BD A8 D2 42
 23 5F C6 54 38 13 09 DF 85 4D BF C3 58 7F 50 B3
 80 D2 D5 03 6E 3E 68 9F DC 48 A6 09 D1 12 83 F5
 CF FE 7D 0F 11 9D CF 1A 87 99 A5 64 1B AB 24 F1
 98 1A 81 84 49 38 1A 0F D6 C8 20 5D 24 5F 02 6F
 49 72 B5 FA 8C 56 46 0B 25 F9 10 DB 0C 20 77 60
 38 1D 18 2E 4C 50 BD 7C A8 64 F5 6E 39 5E 44 62
 7B D5 A7 93 04 3C 71 3C F7 9D B7 B9 42 86 1E 4D
 10 51 C3 26 95 15 2C A1 9D 3D A3 D8 38 31 32 70
 5E F9 B1 8B 30 6A 0E AB 10 7E EA 7C E7 FA 7A 46
 45 81 51 14 28 95 30 51 70 B9 7E C6 87 18 5F D4
 B3 B4 25 1C 73 64 9C 60 AC AB DF F3 6E 54 11 47
 8C 96 6E 88 19 8C 25 B5 74 66 DB 4C FD F0 33 13
 C4 DF 6B 4F 30 1F 94 E6 45 81 12 CD 33 64 69 A1
 7A 20 73 E9 0B 88 FA 1D EF 35 FF 73 6E CC 25 CF
 B1 C0 D2 24 80 97 02 03 01 00 01 A3 82 02 94 30
 82 02 90 30 1A 06 03 55 1D 11 04 13 30 11 82 09
 6F 6D 7A 73 72 76 30 39 30 87 04 A6 25 D6 1E 30
 1D 06 03 55 1D 0E 04 16 04 14 73 F7 B1 30 41 13
 95 DD F2 46 F3 AC B5 C6 45 8C 01 AE 30 F7 30 81
 D5 06 03 55 1D 23 04 81 CD 30 81 CA 80 14 5E 23
 81 53 9C 80 7B B7 E8 26 A3 72 5C 34 98 FC C0 CB
 24 A3 A1 81 9F A4 81 9C 30 81 99 31 20 30 1E 06
 09 2A 86 48 86 F7 0D 01 09 01 16 11 63 65 72 74
 2D 72 65 71 40 77 63 6F 6D 2E 63 6F 6D 31 0B 30
 09 06 03 55 04 06 13 02 55 53 31 0B 30 09 06 03
 55 04 08 13 02 43 4F 31 19 30 17 06 03 55 04 07
 13 10 43 6F 6C 6F 72 61 64 6F 20 53 70 72 69 6E
 67 73 31 0C 30 0A 06 03 55 04 0A 13 03 4D 43 49
 31 0C 30 0A 06 03 55 04 0B 13 03 4E 41 53 31 24
 30 22 06 03 55 04 03 13 1B 4D 43 49 20 54 65 73
 74 20 61 6E 64 20 44 65 76 65 6C 6F 70 6D 65 6E
 74 20 43 41 82 10 2F 06 C1 83 30 75 AF A6 43 FB
 5C 2A A4 FF D5 97 30 81 A5 06 03 55 1D 1F 04 81
 9D 30 81 9A 30 4A A0 48 A0 46 86 44 68 74 74 70
 3A 2F 2F 6E 64 63 6E 61 73 77 65 62 31 2F 43 65
 72 74 45 6E 72 6F 6C 6C 2F 4D 43 49 25 32 30 54
 65 73 74 25 32 30 61 6E 64 25 32 30 44 65 76 65
 6C 6F 70 6D 65 6E 74 25 32 

Re: [classlib][xnet] Problem connecting using SSLSocketImpl

[Alexander Kleymenov]

Hi Gerald,

Boris and I resolved the problem. This was an incorrect Certificate
Verify message sent to the server peer during mutual authentication.
Please try the attached patch and tell us how it works. If it is OK
for you I will attach it to the JIRA report you created (when the
server will work). Please, note – this patch should be applied on the
current JSSE source versions (i.e. without early applied patches).

Actually Harmony supports PKCS12 keystore format. But there is an
issue with using it. We now work on this problem.

Thanks for your collaboration in making Harmony's JSSE Provider more
stable and robust! We really appreciate you support!

Regards,
Alexander Kleymenov
Index: 
modules/x-net/src/main/java/org/apache/harmony/xnet/provider/jsse/DigitalSignature.java
===
--- 
modules/x-net/src/main/java/org/apache/harmony/xnet/provider/jsse/DigitalSignature.java
 (revision 466004)
+++ 
modules/x-net/src/main/java/org/apache/harmony/xnet/provider/jsse/DigitalSignature.java
 (working copy)
@@ -71,6 +71,7 @@
 public DigitalSignature(int keyExchange) {
 try { 
 if (keyExchange == CipherSuite.KeyExchange_RSA_EXPORT ||
+keyExchange == CipherSuite.KeyExchange_RSA ||
 keyExchange == CipherSuite.KeyExchange_DHE_RSA ||
 keyExchange == CipherSuite.KeyExchange_DHE_RSA_EXPORT) {
 // SignatureAlgorithm is rsa
Index: 
modules/x-net/src/main/java/org/apache/harmony/xnet/provider/jsse/ClientHandshakeImpl.java
===
--- 
modules/x-net/src/main/java/org/apache/harmony/xnet/provider/jsse/ClientHandshakeImpl.java
  (revision 466004)
+++ 
modules/x-net/src/main/java/org/apache/harmony/xnet/provider/jsse/ClientHandshakeImpl.java
  (working copy)
@@ -29,6 +29,7 @@
 import java.security.KeyPair;
 import java.security.KeyPairGenerator;
 import java.security.NoSuchAlgorithmException;
+import java.security.PrivateKey;
 import java.security.PrivilegedExceptionAction;
 import java.security.PublicKey;
 import java.security.cert.CertificateException;
@@ -366,6 +367,8 @@
  * client messages, computers masterSecret, sends ChangeCipherSpec
  */
 void processServerHelloDone() {
+PrivateKey clientKey = null;
+
 if (serverCert != null) {
 if (session.cipherSuite.keyExchange == 
CipherSuite.KeyExchange_DH_anon
 || session.cipherSuite.keyExchange == 
CipherSuite.KeyExchange_DH_anon_EXPORT) {
@@ -389,8 +392,10 @@
 .getTypesAsString(),
 certificateRequest.certificate_authorities, null);
 if (clientAlias != null) {
-certs = ((X509ExtendedKeyManager) parameters.getKeyManager())
-.getCertificateChain((clientAlias));
+X509ExtendedKeyManager km = (X509ExtendedKeyManager) parameters
+.getKeyManager();
+certs = km.getCertificateChain((clientAlias));
+clientKey = km.getPrivateKey(clientAlias);
 }
 session.localCertificates = certs;
 clientCert = new CertificateMessage(certs);
@@ -503,27 +508,29 @@
 
 computerMasterSecret();
 
-if (clientCert != null) {
-boolean[] keyUsage = clientCert.certs[0].getKeyUsage();
-if (keyUsage != null  keyUsage[0]) {
-// Certificate verify
-DigitalSignature ds = new DigitalSignature(
-session.cipherSuite.keyExchange);
-if (session.cipherSuite.keyExchange == 
CipherSuite.KeyExchange_RSA_EXPORT
-|| session.cipherSuite.keyExchange == 
CipherSuite.KeyExchange_DHE_RSA
-|| session.cipherSuite.keyExchange == 
CipherSuite.KeyExchange_DHE_RSA_EXPORT) {
-ds.setMD5(io_stream.getDigestMD5());
-ds.setSHA(io_stream.getDigestSHA());
-} else if (session.cipherSuite.keyExchange == 
CipherSuite.KeyExchange_DHE_DSS
-|| session.cipherSuite.keyExchange == 
CipherSuite.KeyExchange_DHE_DSS_EXPORT) {
-ds.setSHA(io_stream.getDigestSHA());
-// The Signature should be empty in case of anonimous 
signature algorithm:
-// } else if (session.cipherSuite.keyExchange == 
CipherSuite.KeyExchange_DH_anon ||
-// session.cipherSuite.keyExchange == 
CipherSuite.KeyExchange_DH_anon_EXPORT) {
-}
-certificateVerify = new CertificateVerify(ds.sign());
-send(certificateVerify);
+// send certificate verify for all certificates except those containing
+// fixed DH parameters
+if (clientCert != null  !clientKeyExchange.isEmpty()) {
+// Certificate verify
+DigitalSignature ds = new 

Re: [classlib] logging (was: Re: [classlib][xnet] Problem connecting using SSLSocketImpl)

[Tim Ellison]

Mikhail Loenko wrote:
 2006/10/17, Alexander Kleymenov [EMAIL PROTECTED]:
 
 Hi Tim
 
 BTW, there are some logging capabilities in JSSE provider. You can 
 turn them on by specifying -Djsse=record,prf,socket as an option to
 VM. Log output could be useful in problem analysis.
 
 You asked why we need logging. Now we have an example.

I maintain that we should not be putting printf's (i.e. calls to
logging) in the Java code.

We are running on a virtual machine that knows everything about the
executing code, what methods are being invoked, the actual arguments,
the state of the stacks and the heap, etc.  There is much more value in
a good trace story built into the VM than having developers decide a
priori where the problems are going to be.

By adding logging calls you have a much more significant effect on the
code base, you hit performance, modify the stack to log the messages,
bloat the code for readability, and by definition introduce more bugs
and maintenance overhead.

If you do want to inject application-level tracing then I'd go for
aspects, which are designed specifically to provide such orthogonal
behavior to the classlib functionality.

If you look here[1] there is a document that describes the diagnostics
capabilities in the IBM VM that we use to support our customers.

[1] http://www-128.ibm.com/developerworks/java/jdk/diagnosis/

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][xnet] Problem connecting using SSLSocketImpl

[Alexander Kleymenov]

Hello Gerald,


Hi Alexander, I'm a bit new at this ASF Harmony stuff so bear with me.


It's OK. We all are involved in a continual learning process.


I'm using Eclipse on Windblows XP.  I set it up per the instructions on the
Apache-Harmony web set for configuring Eclipse to work on Harmony code -
including downloading that VM from IBM.  When I run my class under Eclipse,
here are the console error messages I get:
javax.net.ssl.SSLException: Fatal alert received unexpected_message
   at
org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.processAlert(SSLSocketIm
pl.java:790)
   at
org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.doHandshake(SSLSocketImp
l.java:731)
   at
org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.startHandshake(SSLSocket
Impl.java:437)
   at CreateSSLEng.init(CreateSSLEng.java:72)
   at CreateSSLEng.main(CreateSSLEng.java:93)


Hmm, it is very strange. Stack trace shows that the server side got
unexpected message and reported us about it. In case of unsupported
cipher suites (as we thought) we should receive handshake_failure
alert, not unexpected_message. So the problem here is with client
which sends unexpected message to the server.


I tried the -Djsse=record,prf,socket VM option you suggest (both in the
Target field of the Eclipse shortcut and as a Target Platform/Launching
Arguments VM argument within Eclipse Preferences), but I see nothing in
Eclipse showing this output.  Perhaps there is a log file somewhere?  I
dunno.


I could not reproduce your output. I've tried your code to connect to
the JRockit SSL Server Socket configured to use only
TLS_RSA_WITH_AES_128_CBC_SHA cipher suite. I have started your code
from eclipse and got:

javax.net.ssl.SSLException: Fatal alert received handshake_failure
 at 
org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.processAlert(SSLSocketImpl.java:791)
 at 
org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.doHandshake(SSLSocketImpl.java:732)
 at 
org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.startHandshake(SSLSocketImpl.java:438)

As expected in case of absence of common cipher suite..

I'm not sure but the reason you got handshake_failure alert can be
old SSL version running on the remote side. Harmony's JSSE provider
supports TLS v1 and SSL v3 versions of the protocol, and if the server
uses SSL v2 it simply does not understand the client. If it is
possible try to run the server side with SSL v3 or TLS v1 protocols.

I have added the -Djsse=record,prf,socket option as follows:

Menu Run - Run... , Create, manage, and run configurations window
is appeared. Open (x)= Argument tab and write
-Djsse=record,prf,socket in the VM arguments text window. Then press
Apply and Run.

Please try these steps – there should be log output in Console tab of Eclipse.

Thank You,
Alexander Kleymenov

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib] logging (was: Re: [classlib][xnet] Problem connecting using SSLSocketImpl)

[Alexei Zakharov]

If you do want to inject application-level tracing then I'd go for
aspects, which are designed specifically to provide such orthogonal
behavior to the classlib functionality.


I suppose we still need someone to investigate this field and invent
the acceptable solution. I remember Geir volunteered to do something
in this direction.

Regards,

2006/10/18, Tim Ellison [EMAIL PROTECTED]:

Mikhail Loenko wrote:
 2006/10/17, Alexander Kleymenov [EMAIL PROTECTED]:

 Hi Tim

 BTW, there are some logging capabilities in JSSE provider. You can
 turn them on by specifying -Djsse=record,prf,socket as an option to
 VM. Log output could be useful in problem analysis.

 You asked why we need logging. Now we have an example.

I maintain that we should not be putting printf's (i.e. calls to
logging) in the Java code.

We are running on a virtual machine that knows everything about the
executing code, what methods are being invoked, the actual arguments,
the state of the stacks and the heap, etc.  There is much more value in
a good trace story built into the VM than having developers decide a
priori where the problems are going to be.

By adding logging calls you have a much more significant effect on the
code base, you hit performance, modify the stack to log the messages,
bloat the code for readability, and by definition introduce more bugs
and maintenance overhead.

If you do want to inject application-level tracing then I'd go for
aspects, which are designed specifically to provide such orthogonal
behavior to the classlib functionality.

If you look here[1] there is a document that describes the diagnostics
capabilities in the IBM VM that we use to support our customers.

[1] http://www-128.ibm.com/developerworks/java/jdk/diagnosis/

Regards,
Tim




--
Alexei Zakharov,
Intel Enterprise Solutions Software Division, Russia

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib] logging (was: Re: [classlib][xnet] Problem connecting using SSLSocketImpl)

[Geir Magnusson Jr.]

Alexei Zakharov wrote:

If you do want to inject application-level tracing then I'd go for
aspects, which are designed specifically to provide such orthogonal
behavior to the classlib functionality.


I suppose we still need someone to investigate this field and invent
the acceptable solution. I remember Geir volunteered to do something
in this direction.



Ha!  No, I was hoping George would say something.

I'll start another thread w/ a different idea...

geir


Regards,

2006/10/18, Tim Ellison [EMAIL PROTECTED]:

Mikhail Loenko wrote:
 2006/10/17, Alexander Kleymenov [EMAIL PROTECTED]:

 Hi Tim

 BTW, there are some logging capabilities in JSSE provider. You can
 turn them on by specifying -Djsse=record,prf,socket as an option to
 VM. Log output could be useful in problem analysis.

 You asked why we need logging. Now we have an example.

I maintain that we should not be putting printf's (i.e. calls to
logging) in the Java code.

We are running on a virtual machine that knows everything about the
executing code, what methods are being invoked, the actual arguments,
the state of the stacks and the heap, etc.  There is much more value in
a good trace story built into the VM than having developers decide a
priori where the problems are going to be.

By adding logging calls you have a much more significant effect on the
code base, you hit performance, modify the stack to log the messages,
bloat the code for readability, and by definition introduce more bugs
and maintenance overhead.

If you do want to inject application-level tracing then I'd go for
aspects, which are designed specifically to provide such orthogonal
behavior to the classlib functionality.

If you look here[1] there is a document that describes the diagnostics
capabilities in the IBM VM that we use to support our customers.

[1] http://www-128.ibm.com/developerworks/java/jdk/diagnosis/

Regards,
Tim






-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [classlib][xnet] Problem connecting using SSLSocketImpl

[Gerald Jerome]

Hi Alexander,

I created JIRA report HARMONY-1914 because I could not email a zip
attachment with the debug info you requested from the
-Djsse=record,prf,socket VM argument.  Your help is greatly appreciated.

Gerald Jerome
VerizonBusiness



-Original Message-
From: Alexander Kleymenov [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, October 18, 2006 3:27 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][xnet] Problem connecting using SSLSocketImpl

Hello Gerald,

 Hi Alexander, I'm a bit new at this ASF Harmony stuff so bear with me.

It's OK. We all are involved in a continual learning process.

 I'm using Eclipse on Windblows XP.  I set it up per the instructions on
the
 Apache-Harmony web set for configuring Eclipse to work on Harmony code -
 including downloading that VM from IBM.  When I run my class under
Eclipse,
 here are the console error messages I get:
 javax.net.ssl.SSLException: Fatal alert received unexpected_message
at

org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.processAlert(SSLSocketIm
 pl.java:790)
at

org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.doHandshake(SSLSocketImp
 l.java:731)
at

org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.startHandshake(SSLSocket
 Impl.java:437)
at CreateSSLEng.init(CreateSSLEng.java:72)
at CreateSSLEng.main(CreateSSLEng.java:93)

Hmm, it is very strange. Stack trace shows that the server side got
unexpected message and reported us about it. In case of unsupported
cipher suites (as we thought) we should receive handshake_failure
alert, not unexpected_message. So the problem here is with client
which sends unexpected message to the server.

 I tried the -Djsse=record,prf,socket VM option you suggest (both in the
 Target field of the Eclipse shortcut and as a Target Platform/Launching
 Arguments VM argument within Eclipse Preferences), but I see nothing in
 Eclipse showing this output.  Perhaps there is a log file somewhere?  I
 dunno.

I could not reproduce your output. I've tried your code to connect to
the JRockit SSL Server Socket configured to use only
TLS_RSA_WITH_AES_128_CBC_SHA cipher suite. I have started your code
from eclipse and got:

javax.net.ssl.SSLException: Fatal alert received handshake_failure
  at
org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.processAlert(SSLSocketIm
pl.java:791)
  at
org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.doHandshake(SSLSocketImp
l.java:732)
  at
org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.startHandshake(SSLSocket
Impl.java:438)

As expected in case of absence of common cipher suite..

I'm not sure but the reason you got handshake_failure alert can be
old SSL version running on the remote side. Harmony's JSSE provider
supports TLS v1 and SSL v3 versions of the protocol, and if the server
uses SSL v2 it simply does not understand the client. If it is
possible try to run the server side with SSL v3 or TLS v1 protocols.

I have added the -Djsse=record,prf,socket option as follows:

Menu Run - Run... , Create, manage, and run configurations window
is appeared. Open (x)= Argument tab and write
-Djsse=record,prf,socket in the VM arguments text window. Then press
Apply and Run.

Please try these steps - there should be log output in Console tab of
Eclipse.

Thank You,
Alexander Kleymenov

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][xnet] Problem connecting using SSLSocketImpl

[Alexander Kleymenov]

Hello Gerald!

It is glad to hear that You are trying to use Harmony's JSSE provider!


I'd like to inquire if there is any intention in the future to support any

of the TLS AES type cipher suites?

Now only the base Cipher Suites (described by RFC 2246) are supported.
But the design of the provider allows easily extending its set of suites.
The point for extension is
org.apache.harmony.xnet.provider.jsse.CipherSuiteclass.
Harmony's Cipher provider (implemented by Bouncy Castle) supports AES
Cipher, so it won't be a problem.


If you have any other ideas on what may be causing this exception please

let me know.

I think you are 100% right about the nature of failure, but detailed
information (std output, stack trace) can help to analyze it accurately.
Could you show it please? You may want to file a new JIRA report and provide
this detailed information as an attachment for it. Or if it is more
convenient you can attach zipped info here.
BTW, there are some logging capabilities in JSSE provider. You can turn them
on by specifying
-Djsse=record,prf,socket
as an option to VM. Log output could be useful in problem analysis.

Thank You,
Alexander Kleymenov

[classlib] logging (was: Re: [classlib][xnet] Problem connecting using SSLSocketImpl)

[Mikhail Loenko]

2006/10/17, Alexander Kleymenov [EMAIL PROTECTED]:

Hello Gerald!

It is glad to hear that You are trying to use Harmony's JSSE provider!

 I'd like to inquire if there is any intention in the future to support any
of the TLS AES type cipher suites?

Now only the base Cipher Suites (described by RFC 2246) are supported.
But the design of the provider allows easily extending its set of suites.
The point for extension is
org.apache.harmony.xnet.provider.jsse.CipherSuiteclass.
Harmony's Cipher provider (implemented by Bouncy Castle) supports AES
Cipher, so it won't be a problem.

 If you have any other ideas on what may be causing this exception please
let me know.

I think you are 100% right about the nature of failure, but detailed
information (std output, stack trace) can help to analyze it accurately.
Could you show it please? You may want to file a new JIRA report and provide
this detailed information as an attachment for it. Or if it is more
convenient you can attach zipped info here.


Hi Tim


BTW, there are some logging capabilities in JSSE provider. You can turn them
on by specifying
-Djsse=record,prf,socket
as an option to VM. Log output could be useful in problem analysis.


You asked why we need logging. Now we have an example.

Thanks,
Mikhail



Thank You,
Alexander Kleymenov




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [classlib][xnet] Problem connecting using SSLSocketImpl

[Gerald Jerome]

Hi Alexander, I'm a bit new at this ASF Harmony stuff so bear with me.  I'm
using Eclipse on Windblows XP.  I set it up per the instructions on the
Apache-Harmony web set for configuring Eclipse to work on Harmony code -
including downloading that VM from IBM.  When I run my class under Eclipse,
here are the console error messages I get:
javax.net.ssl.SSLException: Fatal alert received unexpected_message
at
org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.processAlert(SSLSocketIm
pl.java:790)
at
org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.doHandshake(SSLSocketImp
l.java:731)
at
org.apache.harmony.xnet.provider.jsse.SSLSocketImpl.startHandshake(SSLSocket
Impl.java:437)
at CreateSSLEng.init(CreateSSLEng.java:72)
at CreateSSLEng.main(CreateSSLEng.java:93)

Here is my code:
import javax.net.ssl.*;

import org.apache.harmony.xnet.provider.jsse.SSLContextImpl;
import org.apache.harmony.xnet.provider.jsse.SSLSocketImpl;

import java.security.KeyStore;
import java.util.Properties;
import java.io.*;


public class CreateSSLEng {

//   Create/initialize the SSLContext with key material

private int PORT = 0;
private String HOST = null;
Properties safeInterProps = new Properties();
String PropsToUse = safeinter.props;

public CreateSSLEng()
{

try {
safeInterProps.load(new
FileInputStream(PropsToUse));
String
KEYSTORE_FILE=safeInterProps.getProperty(KEYSTORE);
String
PASSWORD=safeInterProps.getProperty(KEY_PASSWD);
String
TRUSTPASSWORD=safeInterProps.getProperty(TRUST_PASSWD);
String
TRUSTSTORE_FILE=safeInterProps.getProperty(TRUSTSTORE);
//   First initialize the key and trust material.
KeyStore ksKeys = KeyStore.getInstance(PKCS12);
KeyStore ksTrust = KeyStore.getInstance(JKS);
ksKeys.load(new FileInputStream(KEYSTORE_FILE),
PASSWORD.toCharArray());
ksTrust.load(new FileInputStream(TRUSTSTORE_FILE),
TRUSTPASSWORD.toCharArray());

//   KeyManager's decide which key material to use.
KeyManagerFactory kmf =
KeyManagerFactory.getInstance(SunX509);
kmf.init(ksKeys, PASSWORD.toCharArray());

//   TrustManager's decide whether to allow connections.
TrustManagerFactory tmf =
TrustManagerFactory.getInstance(SunX509);
tmf.init(ksTrust);

//   We're ready for the engine.
HOST = safeInterProps.getProperty(HOST);
PORT = new
Integer(safeInterProps.getProperty(PORT)).intValue();
SSLContextImpl sslc = new SSLContextImpl();
sslc.engineInit(kmf.getKeyManagers(),
tmf.getTrustManagers(), null);
SSLEngine engine = sslc.engineCreateSSLEngine();

SSLSocketFactory sf = sslc.engineGetSocketFactory();
SSLSocketImpl sock = (SSLSocketImpl) sf.createSocket(HOST,
PORT);
sock.startHandshake();  // Here is where she blows

I tried the -Djsse=record,prf,socket VM option you suggest (both in the
Target field of the Eclipse shortcut and as a Target Platform/Launching
Arguments VM argument within Eclipse Preferences), but I see nothing in
Eclipse showing this output.  Perhaps there is a log file somewhere?  I
dunno.

Thanks,
Gerald Jerome
Vnet 262-2375



-Original Message-
From: Alexander Kleymenov [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 17, 2006 2:27 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][xnet] Problem connecting using SSLSocketImpl

Hello Gerald!

It is glad to hear that You are trying to use Harmony's JSSE provider!

 I'd like to inquire if there is any intention in the future to support any
of the TLS AES type cipher suites?

Now only the base Cipher Suites (described by RFC 2246) are supported.
But the design of the provider allows easily extending its set of suites.
The point for extension is
org.apache.harmony.xnet.provider.jsse.CipherSuiteclass.
Harmony's Cipher provider (implemented by Bouncy Castle) supports AES
Cipher, so it won't be a problem.

 If you have any other ideas on what may be causing this exception please
let me know.

I think you are 100% right about the nature of failure, but detailed
information (std output, stack trace) can help to analyze it accurately.
Could you show it please? You may want to file a new JIRA report and provide
this detailed information as an attachment for it. Or if it is more
convenient you can attach zipped info here.
BTW, there are some logging capabilities in JSSE provider. You can turn them
on by specifying
-Djsse=record,prf,socket
as an option to VM. Log output could be useful in problem analysis.

Thank You,
Alexander Kleymenov