SSL handshake problems with xmlsectool
Wessel, Keith William
kwessel at illinois.edu
Wed Oct 17 16:52:43 EDT 2012
Hi, Scott,
A very good question about why we disabled TLSv1, and I asked. The security guy behind it has left, but the one who I talked to recalls that too many clients out there don't yet support TLSv1.1 and v1.2. So, the safest option, as tey saw it, was to only allow SSLv3. (I'm just repeating what I was told, so I hope that actually makes some sense beyond the abstract level to which it makes sense to me.)
As for debugging, I think you were referring to -Djavax.net.debug=ssl which I enabled but learned little from. It made it through the Hello section of the negociation and seems to have settled on SSLv3, but then the following rather unhelpful exchange occurs. Thoughts on why this is failing?
Keith
*** ClientKeyExchange, RSA PreMasterSecret, SSLv3 main, WRITE: SSLv3 Handshake, length = 260 SESSION KEYGEN:
PreMaster Secret:
0000: 03 00 2C B4 AB 83 BF 2C 4D 0C 09 85 A9 E6 78 40 ..,....,M.....x@
0010: 19 8C 9F 74 D8 FC CF 2D EF 81 70 16 6B B0 06 79 ...t...-..p.k..y
0020: E6 C6 12 71 46 78 09 54 4B AB 71 79 4D 57 86 A7 ...qFx.TK.qyMW..
CONNECTION KEYGEN:
Client Nonce:
0000: 50 7F 19 9C 00 9E 63 94 26 74 C7 A5 21 AF 87 CB P.....c.&t..!...
0010: 2A 8E F1 03 57 0F A8 DA 26 B5 A8 E8 91 66 4D BE *...W...&....fM.
Server Nonce:
0000: 50 7F 19 9C FC D1 E5 7F F9 59 A5 97 74 1C 91 9D P........Y..t...
0010: FE D4 0C B3 70 38 6F A3 AE B0 A1 70 2F C3 A3 C6 ....p8o....p/...
Master Secret:
0000: D7 70 7B B1 F4 C8 B8 A9 C3 44 C3 8F 17 71 59 7F .p.......D...qY.
0010: 0C BB E2 64 36 C0 44 DF D4 A6 55 48 13 2D C8 09 ...d6.D...UH.-..
0020: A6 C4 A6 32 65 6B 99 00 F0 AE 80 0C 44 E4 D3 C7 ...2ek......D...
Client MAC write Secret:
0000: 33 F1 8F 13 70 E3 4A 35 CF 6B 15 BD F9 5B DE 51 3...p.J5.k...[.Q
0010: 9F F8 F9 DA ....
Server MAC write Secret:
0000: 73 F2 54 D7 74 47 74 CD 79 92 54 68 A2 5F E3 5A s.T.tGt.y.Th._.Z
0010: 6F A8 84 54 o..T
Client write key:
0000: 21 27 92 2F EC 61 DD 28 78 83 37 21 84 0E 0E C2 !'./.a.(x.7!....
Server write key:
0000: 6C 3A C7 40 55 C2 B6 44 80 B6 7B 38 11 73 DC E2 l:. at U..D...8.s..
Client write IV:
0000: AB 66 9B DF 5C 02 D6 17 3C 68 C8 D3 16 E3 24 B1 .f..\...<h....$.
Server write IV:
0000: 96 E4 F1 16 AC 8C E4 B3 49 78 93 52 1F 3D D3 ED ........Ix.R.=..
main, WRITE: SSLv3 Change Cipher Spec, length = 1
*** Finished
verify_data: { 221, 194, 93, 15, 152, 90, 75, 86, 12, 195, 244, 159, 226, 205, 192, 64, 215, 217, 191, 139, 165, 26, 176, 209, 124, 100, 136, 168, 63, 27, 76, 27, 77, 4, 205, 51 }
***
main, WRITE: SSLv3 Handshake, length = 64 main, READ: SSLv3 Alert, length = 2 main, RECV SSLv3 ALERT: fatal, bad_record_mac main, called closeSocket() main, handling exception: javax.net.ssl.SSLException: Received fatal alert: bad_record_mac main, called close() main, called closeInternal(true) main, called close() main, called closeInternal(true) main, called close() main, called closeInternal(true) ERROR XmlSecTool - Unable to read XML document from https://itrust-dev.cites.illinois.edu/federationregistry/api/v1/metadata/current
javax.net.ssl.SSLException: Received fatal alert: bad_record_mac
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190) ~[na:1.6]
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:136) ~[na:1.6]
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1839) ~[na:1.6]
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1019) ~[na:1.6]
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1203) ~[na:1.6]
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:654) ~[na:1.6]
at com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:100) ~[na:1.6]
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65) ~[na:1.6.0_35]
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123) ~[na:1.6.0_35]
at org.apache.commons.httpclient.HttpConnection.flushRequestOutputStream(HttpConnection.java:828) ~[commons-httpclient-3.1.jar:na]
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.flushRequestOutputStream(MultiThreadedHttpConnectionManager.java:1565) ~[commons-httpclient-3.1.jar:na]
at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:2116) ~[commons-httpclient-3.1.jar:na]
at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1096) ~[commons-httpclient-3.1.jar:na]
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398) ~[commons-httpclient-3.1.jar:na]
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171) ~[commons-httpclient-3.1.jar:na]
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397) ~[commons-httpclient-3.1.jar:na]
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323) ~[commons-httpclient-3.1.jar:na]
at edu.internet2.middleware.security.XmlSecTool.getXmlInputStreamFromUrl(XmlSecTool.java:270) [xmlsectool-1.1.5.jar:na]
at edu.internet2.middleware.security.XmlSecTool.parseXML(XmlSecTool.java:181) [xmlsectool-1.1.5.jar:na]
at edu.internet2.middleware.security.XmlSecTool.main(XmlSecTool.java:145) [xmlsectool-1.1.5.jar:na]
-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Wednesday, October 17, 2012 3:16 PM
To: Shib Users
Subject: Re: SSL handshake problems with xmlsectool
On 10/17/12 4:00 PM, "Wessel, Keith William" <kwessel at illinois.edu> wrote:
>
>Yes, what was turned off includes TLS. From our httpd.conf:
>
>SSLProtocol All -SSLv2 -TLSv1
Umm, any reason? TLSv1 is a newer SSLv3 in general, and the problems fixed
by TLSv1.1+ affect SSLv3 too.
>Should xmlsectool be trying SSLv3? In other words, is something else to
>blame here?
AFAIK yes, but there lots of things about TLS I don't know.
I believe there's a Java system prop that turns on debugging for SSL in
the JVM. Daniel had me turn that on once to track down the problem with
ldaps name verification, but I don't recall it offhand.
-- Scott
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
More information about the users
mailing list