Hi Chris, Thanks for responding so quickly. My apologies, I should have been clearer on the topology. We have a Tomcat instance with a 3rd party web app deployed on it (the "Tomcat client") running on Windows 2008 . This connects via HTTPS to a 3rd party service running behind IBM Http Server on Solaris 10.
Thanks for clearing up a few things, you dispelled the truststore and handshake assumptions that have clouded some of our conclusions. To answer some of your questions: * our non-production server with the same versions of all client software connects with no errors to a non-production instance of the same 3rd party service using the same cipher suite. So the tool we're using is our 3rd party client Web app (the "Tomcat client"). It shows the same negotiation from TLSv1.2 down to TLSv1. My reading of your comments is that the truststore/keystore has no bearing here because it's an outgoing client connection and there are no inbound connections at play. * I don't know what the highest supported cipher suite is on either client or server hosts. I do know that TLSv1 is the highest supported by the 3rd party server. Unfortunately we have limited control over both client and server hosts because they are provided to us as managed services. However I do know that a standalone Java client successfully connects from our client host to the 3rd party server using TLS_RSA_WITH_AES_128_CBC_SHA, and this shows the same negotiation from TLSv1.2 to TLSv1. * other client applications running lower versions of Tomcat and Java are able to connect to the same 3rd party production service, but at present I don't know what cipher suite they're using * we're not using JCE Unlimited Security because it hasn't been an issue and frankly I didn't think of it when we were doing the installations :) Two additional pieces of analysis that came out of our investigations today are: 1) we are using NextGen Cisco devices. These are application and protocol aware. This means that the firewall might allow allow our standalone Java client to connect using HTTPS, but interfere with the HTTPS SOAP requests from our Tomcat/3rd party app "Tomcat client". 2) there are some anecdotes of Java 7 clients failing to downgrade from TLSv1.2 to TLSv1. For example http://stackoverflow.com/questions/31579587/java-tls-1-2-downgrade-to-tls-1-0-sometimes-error. Some takeaway actions for me to explore are below. I'll welcome any other thoughts that you may have. 1) compare the firewall rules on our working non-production client with the rules governing the failing production client 2) use openssl from our client server and see what it shows 3) consider forcing the Tomcat/3rd party Tomcat client to use TLSv1 4) check other logs on the server side to see if other clients are failing TLS handshakes 5) investigate the supported ciphers on client and server 6) consider upgrading Tomcat (as a last resort) Regards, Diarmuid On 27 Aug 2015 20:36, "Christopher Schultz" <ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Diarmuid, > > On 8/27/15 12:08 PM, dmccrthy wrote: > > We are having a problem with a Tomcat client getting > > "bad_record_mac" exceptions when connecting to a server. Other > > applications are able to connect to that service so this seems > > specific to our client. > > > > I have included a description of the problem, analysis steps > > taken/not yet taken, environment information, and client side logs > > below. > > > > Any insights or suggestions that you may have will be very welcome > > indeed. > > > > Thanks, Diarmuid > > > > > > > > Description of the problem ========================== > > > > On a Windows 2008 R2 64-bit Enterprise server running Java 7u67 and > > Tomcat 7.0.55, outbound SSL connections using TLSv1 and cipher > > suite TLS_RSA_WITH_AES_128_CBC_SHA are failing on the client side > > with "SEND TLSv1 ALERT: fatal, description = bad_record_mac" and > > javax.net.ssl.SSLException: Invalid Padding length errors. This > > uses one-way SSL and there is no Mutual Authentication involved. > > The SSL handshake appears to successfully establish a shared secret > > but fails when it tries to change the new established cipher > > suite. > > So, the server tries to make an outgoing HTTPS request using that > cipher suite? Can you connect to that (other) server directly without > any errors? With that cipher suite? With what tool? > > Or, you can't reach Tomcat directly using some client. I think I'm > confused by the term "Tomcat client". > > > Analysis Steps ============== > > > > 1) On a non-production server with the same JRE/Tomcat/Windows > > setup connecting to a non-production version of the same service. > > This works ok. > > > > 2) On the same non-production server, remove the > > truststore/keystore settings from the Tomcat Java Options and > > connecting to a non-production version of the same service. > > Surprisingly, this works ok even though the endpoint uses a > > self-signed certificate. This connection also uses > > TLS_RSA_WITH_AES_128_CBC_SHA. > > Not surprising to me: if you make an outgoing HTTPS connection from > your application, Tomcat's truststore/keystore don't make any > difference. If you removed your "keystore" configuration and a client > could still connect to your /Tomcat/ server, then something is > definitely broken, because the connector should never have > successfully initialized at all. > > > 3) On the affected production server, run a standalone Java program > > that just opens an SSL input stream to the production service. > > This works ok. > > > > 3) Had a working session with the application team on the server > > side. What they see is: > > > > a) On our affected client, when I query their service from > > Internet Explorer I can successfully retrieve the WSDL and their > > web server records a GET request > > > > b) On our affected client, when I try to invoke a POST request from > > the Tomcat client application, they don't see any traffic on their > > web server and our client fails with the bad_record_mac/Invalid > > Padding Length error > > The error happens before the TLS handshake completes, so you wouldn't > see anything in the access logs. You might want to check other logs, > because you'd want to know if you had clients failing TLS handshakes. > > > 4) Googled for "Invalid Padding length" and cipher > > TLS_RSA_WITH_AES_128_CBC_SHA. There are numerous references to > > this. The most solid is a known Java 7u51 issue recorded here > > https://bugs.openjdk.java.net/browse/JDK-8054316. However this and > > the majority of other TLS Padding links refer to > > javax.net.ssl.SSLHandshakeException or > > "javax.net.ssl.SSLException: Received fatal alert: > > handshake_failure", whereas our situation the handshake is > > completing and on the client we get a "javax.net.ssl.SSLException: > > Invalid Padding length". > > No, your handshake has not completed. Or, possibly, the handshake has > completed, but you aren't able to encrypt anything so it doesn't > matter that you completed the handshake. > > > Aside from that, this article recommends using a different cipher > > suite, but our tests on a different server in step (2) above worked > > with TLS_RSA_WITH_AES_128_CBC_SHA. > > Really you should be using ECDHE or EDHE ciphers these days. I'm not > sure what IIS will actually support (if you are using IIS). You should > allow the server to specify the cipher suite order and make clents use > the highest-grade cipher suite they can support. > > > 5) Read Oracle documentation on debugging SSL/TLS connections here > > http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/Re > adDebug.html. > > > > > What I see from this is: > > > > a) the server is changing the cipher suite rather than the client > > It's a negotiation, not a grudge match. Neither side changes anything. > Did you mean the the server chooses? You're right: the server always > chooses, but sometimes it chooses the first cipher listed by the > client, or it can be told to do something else (use server preferred > order, for instance). > > > b) in our client trace I don't see "Found trusted certificate", > > but based on removing the truststore on a different server in step > > (2) above my conclusion is that this shouldn't matter, or if it did > > matter then the connection would fail with an error like "No > > trusted cert found" > > > > 6) Queried "SEND TLSv1 ALERT: fatal, description = bad_record_mac" > > and "handling exception: javax.net.ssl.SSLException: Invalid > > Padding length" on Stackoverflow but didn't learn much. > > > > 7) Confirmed that other applications can connect to the service > > with no issues > > What is the "client"? > > > 8) Check for differences in Windows patches between the affected > > production server and working non-production server. Using WMIC to > > compare produced the list of patches below which are on the working > > server but not on the failing server. I am working on addressing > > those but analysis of them indicates that they relate to Microsoft > > Office, .NET, and GDI components that are not being used by Tomcat > > or our client application. > > > > http://support.microsoft.com/?kbid=3046017 > > http://support.microsoft.com/?kbid=3060716 > > http://support.microsoft.com/?kbid=3071756 > > http://support.microsoft.com/?kbid=3072305 > > http://support.microsoft.com/?kbid=3075220 > > http://support.microsoft.com/?kbid=3076895 > > http://support.microsoft.com/?kbid=3077657 > > http://support.microsoft.com/?kbid=3078071 > > http://support.microsoft.com/?kbid=3078601 > > http://support.microsoft.com/?kbid=3079757 > > http://support.microsoft.com/?kbid=3087985 > > > > > > 9) Firewall analysis between the client and server shows a mix of > > tcp-fin and tcp-rst commands from the server. However, given that > > no traffic appears on the server-side web server logs it isn't > > clear if this is normal communication or an O/S level issue. > > > > 10) The truststore and keystore are not logged in the Tomcat logs. > > Our tomcat Java Options are below but even removing the double > > quotes makes no difference. I don't know if this is an issue given > > that the non-production test worked ok with no truststore in step > > (2) above > > > > -Dcatalina.home=d:\Tomcat_ENV4 -Dcatalina.base=d:\Tomcat_ENV4 > > -Djava.endorsed.dirs=d:\Tomcat_ENV4\endorsed > > -Djava.io.tmpdir=d:\Tomcat_ENV4\temp > > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager > > -Djava.util.logging.config.file=d:\Tomcat_ENV4\conf\logging.properties > > > > > - -XX:MaxPermSize=1024m > > -Dorg.apache.el.parser.COERCE_TO_ZERO=false -Dfile.encoding=UTF-8 > > -Djavax.net.ssl.trustStore="d:\Tomcat_ENV4\tomcat_truststore.jks" > > -Djavax.net.ssl.trustStorePassword="<snip>" > > -Djavax.net.ssl.keyStore="d:\Tomcat_ENV4\AWCHASSMESA002_keystore.jks > > > > > - -Djavax.net.ssl.keyStorePassword="<snip>" > > -Dhttps.protocols="TLSv1,TLSv1.1,TLSv1.2" > > -Dcom.sun.management.jmxremote > > -Dcom.sun.management.jmxremote.port=9012 > > -Dcom.sun.management.jmxremote.ssl=false > > -Dcom.sun.management.jmxremote.authenticate=false -XX:+UseG1GC > > -XX:NewRatio=4 -XX:InitiatingHeapOccupancyPercent=75 > > -Djavax.net.debug=ssl:handshake > > > > 11) Googled the Tomcat Users forum with the phrases "tomcat_users > > SEND TLSv1 ALERT: fatal, description = bad_record_mac" and > > "tomcat_users SEND TLSv1 ALERT: fatal, description = > > bad_record_mac" > > > > This link > > http://security.stackexchange.com/questions/39844/getting-ssl-alert-wr > ite-fatal-bad-record-mac-during-openssl-handshake > > > > > suggests > > that there might be: > > > > a) a mismatch between the server public and private keys - it > > suggests using wireshark to get the server public key for > > comparison with the server private key > > A mismatch between the server private and public keys is nearly > impossibly to accomplish. > > > b) a buggy cryptographic algorithm on either the client or server - > > it suggests using openssl to analyse this > > This is possible. > > > Analysis not yet done ===================== > > > > 1) Use openssl on the affected server > > Do this. > > > 2) Install Windows Network Monitor or Wireshark on the affected > > client server > > Don't waste your time with this. > > > Client software versions ======================== > > > > 1) Java > > > > java version "1.7.0_67" Java(TM) SE Runtime Environment (build > > 1.7.0_67-b01) Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, > > mixed mode) > > > > JCE Unlimited Security: No > > Why not? > > > 2) Tomcat > > > > Apache Tomcat/7.0.55 > > > > 3) Operating System > > > > C:\>wmic os get name > > > > Name > > > > Microsoft Windows Server 2008 R2 Enterprise > > |C:\Windows|\Device\Harddisk0\Partition2 > > > > > > C:\>wmic os get buildnumber, buildtype, version > > > > BuildNumber BuildType Version > > > > 7601 Multiprocessor Free 6.1.7601 > > > > > > C:\>wmic os get servicepackmajorversion, servicepackminorversion > > > > ServicePackMajorVersion ServicePackMinorVersion > > > > 1 0 > > > > C:\>wmic os get operatingsystemsku > > > > OperatingSystemSKU > > > > 10 > > > > Server versions =============== > > > > Web server: IBM HTTP Server 6.1 Java: none OS: Solaris 10 > > DataPower: No > > > > > > Client Log File Extract using -Djavax.net.debug=ssl:handshake > > > > ============================================================= > > > > > > Ignoring unavailable cipher suite: > > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher > > suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher > > suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA Ignoring unsupported > > cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 Ignoring > > unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 > > Ignoring unsupported cipher suite: > > TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 Ignoring unsupported cipher > > suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 Ignoring unsupported > > cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 Ignoring > > unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 > > Ignoring unsupported cipher suite: > > TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 Ignoring unsupported cipher > > suite: TLS_RSA_WITH_AES_256_CBC_SHA256 Ignoring unavailable cipher > > suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA Ignoring unsupported > > cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 Ignoring > > unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 > > Ignoring unavailable cipher suite: > > TLS_DHE_DSS_WITH_AES_256_CBC_SHA Ignoring unsupported cipher suite: > > TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 Ignoring unsupported cipher > > suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 Ignoring unsupported > > cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 Ignoring > > unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA > > Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA > > Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256 > > > > Allow unsafe renegotiation: false Allow legacy hello messages: > > true Is initial handshake: true Is secure renegotiation: false > > schedulerFactory_Worker-8, setSoTimeout(0) called > > > > %% No cached client session > > > > *** ClientHello, TLSv1.2 > > > > RandomCookie: GMT: 1423675093 bytes = { 59, 69, 104, 56, 82, 159, > > 163, 199, 164, 17, 202, 162, 164, 138, 227, 23, 72, 131, 9, 12, > > 170, 240, 164, 81, 78, 211, 18, 182 } > > > > Session ID: {} > > > > Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, > > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, > > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, > > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, > > TLS_DHE_RSA_WITH_AES_128_CBC_SHA, > > TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, > > TLS_ECDHE_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, > > TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, > > TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, > > TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, > > SSL_RSA_WITH_3DES_EDE_CBC_SHA, > > TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, > > TLS_ECDH_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_RC4_128_MD5, > > TLS_EMPTY_RENEGOTIATION_INFO_SCSV] > > > > Compression Methods: { 0 } > > > > Extension elliptic_curves, curve names: {secp256r1, sect163k1, > > sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, > > sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, > > sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, > > sect193r1, sect193r2, secp224k1, sect239k1, secp256k1} > > > > Extension ec_point_formats, formats: [uncompressed] > > > > Extension signature_algorithms, signature_algorithms: > > SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, > > SHA256withECDSA, SHA256withRSA, SHA224withECDSA, SHA224withRSA, > > SHA1withECDSA, SHA1withRSA, SHA1withDSA, MD5withRSA > > > > Extension server_name, server_name: [host_name:dbgsvc.com] > > > > *** > > > > schedulerFactory_Worker-8, WRITE: TLSv1.2 Handshake, length = 202 > > > > schedulerFactory_Worker-8, READ: TLSv1 Handshake, length = 874 > > > > *** ServerHello, TLSv1 > > > > RandomCookie: GMT: 85 bytes = { 248, 101, 199, 189, 146, 96, 91, > > 4, 35, 49, 184, 57, 70, 109, 49, 169, 202, 62, 196, 132, 153, 140, > > 11, 62, 238, 254, 62, 248 } > > > > Session ID: {0, 0, 75, 106, 51, 228, 118, 38, 226, 191, 94, 148, > > 108, 7, 1, 26, 35, 185, 139, 243, 88, 88, 88, 88, 85, 220, 143, > > 212, 0, 0, 1, 243} > > > > Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA > > > > Compression Method: 0 > > > > *** > > > > Warning: No renegotiation indication extension in ServerHello > > > > %% Initialized: [Session-1288, TLS_RSA_WITH_AES_128_CBC_SHA] > > > > ** TLS_RSA_WITH_AES_128_CBC_SHA > > > > *** Certificate chain > > > > chain [0] = [ > > > > [ > > > > Version: V3 > > > > Subject: CN=dbgsvc.com, OU=Middleware, O=dbg, C=US > > > > Signature Algorithm: SHA1withRSA, OID = 1.2.840.113549.1.1.5 > > > > > > > > Key: Sun RSA public key, 2048 bits > > > > modulus: > > 2741662562150850327055415152209274148202047748967874572630723082365466 > 020223847769717091250582336030862018053574568365844743246626039537030813 > 564616582990838439119746438282044526712658164803731550202737875403242687 > 855940835709848511214890868675052732357656769564118614472058800842187012 > 113842068923050951223218423752597595319310868313091636941020456697814669 > 284909530507036647240097211671015895967062415399347301451715750571927486 > 890789301190240877510933568087945249396473115318481006419465625461223356 > 326134475752539114546085875225721620932883444551510480273599575498664415 > 6237721271016494185419847066126313124298401 > > > > public exponent: 65537 > > > > Validity: [From: Tue Jan 13 15:22:34 CAT 2015, > > > > To: Fri Jan 10 15:22:34 CAT 2025] > > > > Issuer: CN=dbgsvc.com, OU=Middleware, O=dbg, C=US > > > > SerialNumber: [ 54b51c1a] > > > > > > > > ] > > > > Algorithm: [SHA1withRSA] > > > > Signature: > > > > 0000: A3 75 13 D5 3B 9B B1 D5 44 39 2F 31 93 2E 9F 5F > > .u..;...D9/1..._ > > > > 0010: 86 61 4D 1F AA 0E 25 BA 70 26 13 93 F5 6E 73 7C > > .aM...%.p&...ns. > > > > 0020: 23 A5 E1 A0 96 7C F9 A0 A3 B4 09 B8 29 2C BC C0 > > #...........),.. > > > > 0030: 5F E4 9D 96 FE 18 B5 BF 05 B5 5D 16 87 E3 DB 77 > > _.........]....w > > > > 0040: 1C 92 5A C5 99 65 4B BE 68 76 AF C1 04 CA EF 6D > > ..Z..eK.hv.....m > > > > 0050: 2D 56 5C BB AE A4 87 4E EB 88 D7 60 0F 74 30 80 > > -V\....N...`.t0. > > > > 0060: 47 F8 E0 74 8B 8B 73 C2 84 87 9B 64 5E FC B7 D7 > > G..t..s....d^... > > > > 0070: 6E F8 F5 24 9B B2 10 2B 2B 94 33 26 06 BC 62 21 > > n..$...++.3&..b! > > > > 0080: 4D C1 B4 BB 98 35 5F BF 18 21 C6 C1 98 EA 20 D5 > > M....5_..!.... . > > > > 0090: 8E C3 4D C5 1A 9C B9 21 FA B1 1B 1D 74 05 31 1A > > ..M....!....t.1. > > > > 00A0: C0 19 CD E2 22 81 FC 36 57 D6 86 29 FD 76 FA 97 > > ...."..6W..).v.. > > > > 00B0: D8 F3 06 55 15 2D B8 87 FB 34 92 5E 7B 53 CA 17 > > ...U.-...4.^.S.. > > > > 00C0: 27 9F 6D 45 86 C3 FD 60 93 51 27 39 AA 95 9D 26 > > '.mE...`.Q'9...& > > > > 00D0: 8C DB CE FC 3F E8 FA 09 4B 49 AF E8 6A 91 C3 C6 > > ....?...KI..j... > > > > 00E0: 1D D6 48 D7 EF B5 55 B2 CC 1F 17 D0 37 DF CE 09 > > ..H...U.....7... > > > > 00F0: 6A 30 11 C0 28 05 E4 C6 88 F9 3E C6 26 36 58 D9 > > j0..(.....>.&6X. > > > > > > > > ] > > > > *** > > > > *** ServerHelloDone > > > > *** ClientKeyExchange, RSA PreMasterSecret, TLSv1 > > > > schedulerFactory_Worker-8, WRITE: TLSv1 Handshake, length = 262 > > > > SESSION KEYGEN: > > > > PreMaster Secret: > > > > 0000: 03 03 3C 7D 72 98 C9 9E 1C 14 6B CF CD EE 04 28 > > ..<.r.....k....( > > > > 0010: 4A 1A 25 5E 66 37 E4 56 98 66 83 60 51 E9 8A E0 > > J.%^f7.V.f.`Q... > > > > 0020: CA 4B 88 D1 9E 9F 34 FF B0 A3 02 E5 14 1D AC 44 > > .K....4........D > > > > CONNECTION KEYGEN: > > > > Client Nonce: > > > > 0000: 55 DC 8F D5 3B 45 68 38 52 9F A3 C7 A4 11 CA A2 > > U...;Eh8R....... > > > > 0010: A4 8A E3 17 48 83 09 0C AA F0 A4 51 4E D3 12 B6 > > ....H......QN... > > > > Server Nonce: > > > > 0000: 00 00 00 55 F8 65 C7 BD 92 60 5B 04 23 31 B8 39 > > ...U.e...`[.#1.9 > > > > 0010: 46 6D 31 A9 CA 3E C4 84 99 8C 0B 3E EE FE 3E F8 > > Fm1..>.....>..>. > > > > Master Secret: > > > > 0000: 6D AC 3B 14 7B 97 FB 52 80 3D 82 10 AB E9 00 43 > > m.;....R.=.....C > > > > 0010: 06 01 F9 1C C2 62 8F C1 70 9B B6 E3 54 59 1B 7E > > .....b..p...TY.. > > > > 0020: 2B B9 F4 54 17 51 CA 99 D3 03 ED 17 E8 CE 93 30 > > +..T.Q.........0 > > > > Client MAC write Secret: > > > > 0000: B9 73 E9 31 9E 93 04 C7 A1 C1 2D 19 4F 32 BA D9 > > .s.1......-.O2.. > > > > 0010: 95 C8 8E FD .... > > > > Server MAC write Secret: > > > > 0000: 0C 47 2A 24 AA 73 67 A5 71 22 EF A8 AB 2D 3C 65 > > .G*$.sg.q"...-<e > > > > 0010: D5 A6 45 FE ..E. > > > > Client write key: > > > > 0000: 0D A4 BB 9F 81 2E EB C5 E7 57 56 03 CE BD A0 A9 > > .........WV..... > > > > Server write key: > > > > 0000: 6C 12 B0 7B 37 DB C8 0E AE 00 E1 40 5F A3 AE E3 > > l...7......@_... > > > > Client write IV: > > > > 0000: 71 F9 65 D0 9C 03 4F A2 F3 71 08 BD 12 EB F6 48 > > q.e...O..q.....H > > > > Server write IV: > > > > 0000: 8A F4 74 FC 17 5A 43 85 F2 2E CB E7 4B 55 23 04 > > ..t..ZC.....KU#. > > > > schedulerFactory_Worker-8, WRITE: TLSv1 Change Cipher Spec, length > > = 1 > > > > *** Finished > > > > verify_data: { 164, 98, 156, 19, 91, 248, 251, 65, 109, 13, 178, > > 66 } > > > > *** > > > > schedulerFactory_Worker-8, WRITE: TLSv1 Handshake, length = 48 > > > > schedulerFactory_Worker-8, READ: TLSv1 Change Cipher Spec, length = > > 1 > > > > schedulerFactory_Worker-8, READ: TLSv1 Alert, length = 32 > > > > %% Invalidated: [Session-1288, TLS_RSA_WITH_AES_128_CBC_SHA] > > > > schedulerFactory_Worker-8, SEND TLSv1 ALERT: fatal, description = > > bad_record_mac > > > > schedulerFactory_Worker-8, WRITE: TLSv1 Alert, length = 32 > > > > schedulerFactory_Worker-8, called closeSocket() > > > > schedulerFactory_Worker-8, handling exception: > > javax.net.ssl.SSLException: Invalid Padding length: 137 > > > > schedulerFactory_Worker-8, called close() > > > > schedulerFactory_Worker-8, called closeInternal(true) > > > > You might also want to try updating to 7.0.64 (latest as of this > writing). But at this point, you don't have a reproducible test case > outside of production, so it would be a wild guess and might not work. > > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJV32aXAAoJEBzwKT+lPKRYFVgP/3oQy1vw/6BKmbg6WLmXzfcx > zAuosap72NhcTNOVA8wHV8HWT7DqZNKcu/TRqagYBvBz6zTa0aCEQbXMMHpwHA1D > vuEil5+Xh/VN8Gp9n27UcfRgSIdg1ZoGtExYHJahX5/BKbQ6pHBWdx+qKPF7e5kW > 94H04earvOlFmmCSfUf2a6YkATTBICWHPjcnfGrkQwADY4EbwzlEcFLhRvF9uVE0 > hoEbmTnmS+ChfdyWJpXiDpM7MxSCVsiK67hVfohnl46PuvAsDfpLfmNetsxzMEv2 > /0AbNkiHcX/txgJ5v1/bu2cYi9mYQ1/J0i5ueNJFuMqX7zoS40eLsI1MjVbeuT/m > AJPvjwLS8Tpkb37ByEWcJPyHSyz5vA0kPeVjG7fwdBYqSlyVFI8MFMnGCDuWmR1S > m8EYpaWmEcple7pGzvA6ii6cWR9yPygY465huoVeiTfOyXsMiyfx7rkqsRMuKwOv > N2pacMfFDmWsbYCldbTiB4wpKIo/a1mdjsJRNiEXlWPiobpUjwTbnqDXOg/IWVZF > hlvBaWD+71UaDWyBxsGuzywjFWiUHZUUoFyFIix+HrX0bi3CBfO8+e+X1idXac88 > 0ieFVSmhwt+LKvxTnZZDp/zhVjSjhyYYC7Sd2hEU3RcH17D2XUwwSdIYbLtW1I9x > +AlDGZosfVaiCZs1xZsH > =Xbln > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
