FW: Issue with Tomcat Version 7.0.64

[kasturi]

Hi Christopher,

Apologies for the formatting issue. Hope the below shared details helps clarify 
the issue.

Our application has a customized valve called CiscoSSOValve.java which extends 
SingleSignOn.java of catalina.jar. 
SingleSignOn.java of catalina.jar has gone in some changes in 7.0.64. PFB the 
list of changes for which we are facing issues.

1. sessionEvent() method which existed in earlier releases is not present any 
more. We are overriding this method in our customized valve, hence facing 
compilation error where it tries to do a super.sessionEvent(event) call.
2. A new class SingleSignOnListener.java has been introduced in 7.0.64 having 
the same sessionEvent() method mentioned in issue 1. We tried using this method 
but unable to do so as its constructor requires a valid 'SSOId' to be passed.
3. 'SSOId' was earlier retrievable from 'reverse' map of SingleSignOn.java 
class. This map is not present in the 7.0.64 release, so we are unable to fetch 
the 'SSOId' here and pass it in the call to constructor of 
SingleSignOnListener.java as a workaround for issue1.

Compilation errors we are facing are:

[javac] 
/data/shared_ws/jasper/kneogy_stashNew/un_CUSA/Projects/cisco-unity-valve/src/com/cisco/unity/tomcat/valve/CiscoSSOValve.java:91:
 error: cannot find symbol
[javac] synchronized (reverse) {
[javac]   ^
[javac]   symbol:   variable reverse
[javac]   location: class CiscoSSOValve
[javac] 
/data/shared_ws/jasper/kneogy_stashNew/un_CUSA/Projects/cisco-unity-valve/src/com/cisco/unity/tomcat/valve/CiscoSSOValve.java:92:
 error: cannot find symbol
[javac] ssoId = reverse.get(session);
[javac] ^
[javac]   symbol:   variable reverse
[javac]   location: class CiscoSSOValve
[javac] 
/auto/ipcbu-ucxn-cache/CORES/BLD-cc_mainline_16-cct-ccm-d/unityconnection/CLNX_11.5.0.98/source/un_CUSA/Projects/cisco-unity-valve/src/com/cisco/unity/tomcat/valve/CiscoSSOValve.java:98:
 error: cannot find symbol
[javac] super.sessionEvent(event);
[javac]  ^
[javac]   symbol: method sessionEvent(SessionEvent)
[javac] 
/auto/ipcbu-ucxn-cache/CORES/BLD-cc_mainline_16-cct-ccm-d/unityconnection/CLNX_11.5.0.98/source/un_CUSA/Projects/cisco-unity-valve/src/com/cisco/unity/tomcat/valve/CiscoSSOValve.java:100:
 error: cannot find symbol
[javac] if(null != lookup(ssoId))
[javac]^
[javac]   symbol:   method lookup(String)
[javac]   location: class CiscoSSOValve
[javac] 
/auto/ipcbu-ucxn-cache/CORES/BLD-cc_mainline_16-cct-ccm-d/unityconnection/CLNX_11.5.0.98/source/un_CUSA/Projects/cisco-unity-valve/src/com/cisco/unity/tomcat/valve/CiscoSSOValve.java:149:
 error: associate(String,Session) in CiscoSSOValve cannot override 
associate(String,Session) in SingleSignOn
[javac] protected void associate(String ssoId, Session session) {
[javac]^
[javac]   return type void is not compatible with boolean


Thanks and regards,
Kasturi



-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Wednesday, October 14, 2015 1:50 AM
To: Tomcat Users List
Subject: Re: Issue with Tomcat Version 7.0.64

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Kasturi,

On 10/13/15 9:59 AM, kasturi wrote:
> We have recently upgraded Tomcat to 7.0.64 from 7.0.59. Our 
> application extends SingleSignOn.java of catalina.jar to create a 
> wrapper around it. Some methods in the SingleSignOn.java class has 
> been deprecated because of which the compilation is failing.
> Details shared below.
> 
> Catalina 7.0.59
> 
> Catalina 7.0.64

The list has ruined your formatting. Can you post with a text-only message?

> //SingleSingOn Class
> 
> protected Map reverse = new HashMap();
> 
> public void sessionEvent(SessionEvent event)
> 
> {
> 
> if (!getState().isAvailable()) {
> 
> return;
> 
> }
> 
> if ((!"destroySession".equals(event.getType())) &&
> (!"passivateSession".equals(event.getType( {
> 
> return;
> 
> }
> 
> Session session = event.getSession();
> 
> if (this.containerLog.isDebugEnabled()) {
> 
> this.containerLog.debug("Process session destroyed on " + session);
> 
> }
> 
> String ssoId = null;
> 
> synchronized (this.reverse)
> 
> {
> 
> ssoId = (String)this.reverse.get(session);
> 
> }
> 
> if (ssoId == null) {
> 
> return;
> 
> }
> 
> if (((session.getMaxInactiveInterval() > 0) &&
> (System.currentTimeMillis() - session.getThisAccessedTimeInternal()
> >= session.getMaxInactiveInterval() * 1000)) ||
> ("passivateSession".equals(event.getType())) ||
> (!session.getManager().getContainer().getState().isAvailable())) {
> 
> removeSession(ssoId, session);
> 
> } else {
> 
> deregister(ssoId);
> 
> }
> 
> }
> 
> 
> 
> 
> 
> 
> 
> 
> 
> //SingleSingOn Class
> 
> 
> 
> Reverse Map does not exist

That doesn't look like a compiler message.

> sessionEvent() Method does not exist

Nor 

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

[George Stanchev]

So this time I spoke too soon. I was relying on Java to dump in its debug 
trace. Running rawcap/wireshark does reveal that Java indeed wraps the TLSv1.2 
hello payload in SSLv2Hello record envelope which that legacy protocol enables. 
The Java piece of code that I quoted was for the content of the ClientHello 
record, not how it is wrapped which happens later when the record is being 
serialized to the socket...

Anyways, thanks to all for the tip but it doesn't make a difference...still bad 
mac record...

George

-Original Message-
From: George Stanchev [mailto:gstanc...@serena.com] 
Sent: Tuesday, October 13, 2015 3:56 PM
To: Tomcat Users List
Subject: RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

May be I am mistaken. I will give jtouch a try, thanks for the pointers...at 
this point I am grasping at straws :)

Thanks Aurelien!

-Original Message-
From: Aurélien Terrestris [mailto:aterrest...@gmail.com]
Sent: Tuesday, October 13, 2015 3:52 PM
To: Tomcat Users List
Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

"Another route to try the SSLv2Hello is to hack and recompile the JSSE.
It's on my agenda to learn to do that if possible without rebuilding the whole 
JRE since for some obscure reason Oracle compiles JSSE with no debug info (and 
it is not included in the srcs distributed with the JRE) on it which makes 
debugging and inspecting local vars really hard..."

No, it's not needed. I use jtouch.sourceforge.net and it's working well for 
trying SSLv2 hello's. From the network captures, I see that it's working.
Not making advertisement for my software here, but,.. ;)







2015-10-13 23:20 GMT+02:00 George Stanchev :

> Just as a side note, https.protocols is read by HttpsUrlConnection 
> which feeds it down through setEnabledProtocols() on the SSL socket. "
> jdk.tls.client.protocols" is read directly by JSSE and does the same 
> thing...
>
> Another route to try the SSLv2Hello is to hack and recompile the JSSE.
> It's on my agenda to learn to do that if possible without rebuilding 
> the whole JRE since for some obscure reason Oracle compiles JSSE with 
> no debug info (and it is not included in the srcs distributed with the
> JRE) on it which makes debugging and inspecting local vars really hard...
>
> George
>
> -Original Message-
> From: Aurélien Terrestris [mailto:aterrest...@gmail.com]
> Sent: Tuesday, October 13, 2015 3:13 PM
> To: Tomcat Users List
> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, 
> description = bad_record_mac
>
> Maybe writing too fast..
>
> "How do you force Java 8 to use SSLv2Hello?"
>
> As suggested before, by writing your own client OR by trying this hack.
> From the JSSE Ref Guide 5, we know how to the customize the protocol ( 
> https://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefG
> uide.html#InstallationAndCustomization
> ) by setting a system property (https.protocol). Although they are no 
> more talking about this in the Ref Guide 8 ( 
> https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunPro
> viders.html#SunJSSEProvider
> ) I would give it a try as I know that the documentation is poorly written.
> I suggested 10 years ago a change in the API doc about the enabled 
> protocols, and they didn't change anything although they said they would.
>
>
>
> "[1] states: " JDK 7-9 enables SSLv2Hello on the server side only.  
> (Will not send, but will accept SSLv2Hellos)""
>
> I believe they mean "by default" as for the client side. Poorly 
> written, probably.
>
>
>
> 2015-10-13 22:55 GMT+02:00 Aurélien Terrestris :
>
> > "How do you force Java 8 to use SSLv2Hello?"
> >
> > You can do this when writing your own Java client : calling the 
> > SSLSocketFactory to create an SSLSocket and configure with 
> > setEnabledProtocols ( 
> > https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocket.ht
> > ml
> > #setEnabledProtocols-java.lang.String:A-
> > )
> >
> > If you have some IIS server on internet which reproduces the 
> > problem, I'll try with JTouch ( jtouch.sourceforge.net ) or write a small 
> > client.
> >
> >
> >
> >
> > 2015-10-13 22:22 GMT+02:00 Aurélien Terrestris :
> >
> >> George,
> >>
> >> do you have any network capture that we can see ?
> >>
> >> 2015-10-13 22:10 GMT+02:00 George Stanchev :
> >>
> >>> >> It might be doable with OpenSSL s_client or something. Tough to
> >>> replicate Java's behavior with a non-Java tool, though.
> >>>
> >>> I tried hard with the s_client but it can limit the protocols to 
> >>> one or another but it canot mix-and-match (hello 1.2, ok we will 
> >>> do 1.0) like Java
> >>> 8 does. Either TLSv1 or TLSv1.2 but not both. Neither can curl 
> >>> which is also on top of openssl.
> >>>
> >>> Today, I spent 2.5 hours with a lemming from MS getting basically 
> >>> 

Re: Monitoring Connections

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jamie,

On 10/9/15 10:03 AM, Jamie Jackson wrote:
> Here's the stack trace dump: 
> https://gist.github.com/jamiejackson/ca2a49d2c8afac496067
> 
> FWIW, I've been trying to come up with a reliable test case to
> trigger the problem, but I haven't nailed it yet. I've suspected
> that it's related to file (large or slow) HTTP file uploads, and
> that's what I was running at the time, which helps to explain the
> java.net.SocketInputStream.socketRead0 traces.

Your server looks mostly idle. It also looks like it's running both
Tomcat and Jetty in the same instance. What's going on?

> "http-bio--exec-19" Id=27307 RUNNABLE (in native) 
> java.lang.Thread.State: RUNNABLE at
> java.net.SocketInputStream.socketRead0(Native Method) at
> java.net.SocketInputStream.read(SocketInputStream.java:152) at
> java.net.SocketInputStream.read(SocketInputStream.java:122) at
> org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:535)
>
> 
at
org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:504)
> at
> org.apache.coyote.http11.InternalInputBuffer$InputStreamInputBuffer.doRead(InternalInputBuffer.java:566)
>
> 
at
org.apache.coyote.http11.filters.IdentityInputFilter.doRead(IdentityInputFilter.java:137)
> at
> org.apache.coyote.http11.AbstractInputBuffer.doRead(AbstractInputBuffer.java:348)
>
> 
at org.apache.coyote.Request.doRead(Request.java:422)
> at
> org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:290)
>
> 
at org.apache.tomcat.util.buf.ByteChunk.substract(ByteChunk.java:390)
> at
> org.apache.catalina.connector.InputBuffer.readByte(InputBuffer.java:304)
>
> 
at
org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:106)
> at
> com.intergral.fusionreactor.j2ee.filter.surrogate.FusionReactorServletRequestProxy$1.read(FusionReactorServletRequestProxy.java:123)
>
> 
at java.io.InputStream.read(InputStream.java:179)
> at
> org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:977)
>
> 
at
org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(MultipartStream.java:887)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:273) 
> at java.io.BufferedInputStream.read(BufferedInputStream.java:334) -
> locked java.io.BufferedInputStream@6e81abfc at
> java.io.FilterInputStream.read(FilterInputStream.java:107)

Obviously, this thread is reading a file upload. Also these:

"http-bio--exec-21" Id=27309 RUNNABLE (in native)
   java.lang.Thread.State: RUNNABLE
"http-bio--exec-26" Id=27314 RUNNABLE (in native)
   java.lang.Thread.State: RUNNABLE

This thread is making an outgoing HTTP request, which could be hanging:

> "Thread-27550" Id=27623 RUNNABLE (in native) 
> java.lang.Thread.State: RUNNABLE at
> java.net.SocketInputStream.socketRead0(Native Method) at
> java.net.SocketInputStream.read(SocketInputStream.java:152) at
> java.net.SocketInputStream.read(SocketInputStream.java:122) at
> sun.security.ssl.InputRecord.readFully(InputRecord.java:442) at
> sun.security.ssl.InputRecord.read(InputRecord.java:480) at
> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:934) -
> locked java.lang.Object@659eed19 at
> sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:891)
>
> 
at sun.security.ssl.AppInputStream.read(AppInputStream.java:102)
> - locked sun.security.ssl.AppInputStream@7c98d0ab at
> org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:160)
>
> 
at
org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:84)
> at
> org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:273)
>
> 
at
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)
> at
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
>
> 
at
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at
> org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:283)
>
> 
at
org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:251)
> at
> org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:197)
>
> 
at
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
>
> 
at
org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:685)
> at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:487)
>
> 
at
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882)
> at
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
>
> 
at 

Re: JDBC PoolExhaustedException

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Nathan,

On 10/9/15 4:11 PM, Nathan Boyce wrote:
> Does the tomcat jdbc pool use its own executor or does it share
> the executor that's calling it?

A connection pool rarely has a thread pool associated with it: it's
just a repository for connections. Most pools have an optional
"cleaner" thread, but its usually one thread that does the cleaning
separate from any client code.

> Reason I ask is the pool size is set to 320 but only 84 show busy.
> The default tomcatThreadPool executor has been removed from this
> config and executor with the name AJPThreadPool has been added for
> the ajp connections. The ajp thread pool is maxing out but unable
> to tell is it's the cause or effect.
> 
> Server.xml config  maxThreads="750" minSpareThreads="10" maxIdleTime="1" 
> prestartminSpareThreads="true"/>
> 
> Error org.apache.tomcat.jdbc.pool.PoolExhaustedException:
> [ajp-693] Timeout: Pool empty. Unable to fetch a connection in 10
> seconds, none available[size:320; busy:84; idle:0;
> lastwait:1].

Is there anything else in the log?

Perhaps a new connection cannot be created. Resource limit on the
server, maybe?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWHQrdAAoJEBzwKT+lPKRYO1MQAMMsq3OBnCuMlVYU4e4u6SHV
1n/TNmFScTAgMusYzDMca/Q4Vkxq61FSpRPJS95e/YzfiQ5Z9W/jChZl2vK11Zn5
uNst2j7m4FYNe5eupuyCKxpYgTvP4kT+vYMgz9hqqxctqyWVHIHp44W88hnH6pxi
vcmeXnWQeq8QwDYzGyF9MDEzQI6PRcA/aUK0cgg6nwcHulSZ01anTRpmgH/10qe0
nF2AOlUvS2mkFAJy5FXzJJU4gCGyWhkovuJvbliJcBceMDmMuIJ6i8DHVQcSSW8c
I7AwlNYDbPe3ZuxwRSzmVH7MkRRPbPqWBTf2Ws8J0uUBXI9B9VxdOEYAoJyTmeQp
tSQVQxUic5MsK3pUbQEJvlEvLgZcK86nGXPiq0QT8WBLpdQZTqqcitvjw6Z2iSqL
cF+fAwSOcSUujB9lDv0rYVkyg0CdRnSRxkLb0q90qZbfsNAg4HokIasZyQO0Jw6x
1ogN62VGERA1zslBGOCK31w4O6EU3+5IJEHPu6UmOHqbAewYgoUNuWt3g0jtMi6Z
C1CroUNR15sr0kUQUx7sZYnUie1JsSP8Lxzenu1B0aySHDZID4HxyNCUsmh8ub7t
dQhVHLKtajKCWHcVWxPCzIyClAMiBFpxElnT+z6f7CUnlRYIKQMa9mj5MYDol0IM
6Xrzyb5XWYmXgI+18urK
=HUC0
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat 8 Rewrite Valve

[Theo . Sweeny]

Hello - I'm having issues implementing a HTTP 301 redirect via the Rewrite 
Valve module.

Ref - https://tomcat.apache.org/tomcat-8.0-doc/rewrite.html

Tomcat v8.021 is running on Ubuntu 14.04 x64.

The requirement is to run the rewrite config globally for all webapps, for 
this reason the valve is set inside the host.

conf/server.xml









Redirect set inside - conf/Catalina/localhost/rewrite.config

RewriteCond %{REQUEST_URI}  ^/abc/key$
RewriteRule ^/abc/key(.*)   /audit-management-ds-1.0/info 
[R=301,L]

Test - curl -vv -X GET http://ubt-srv-14-01:10080/abc/key

* Hostname was NOT found in DNS cache
*   Trying 127.0.1.1...
* Connected to ubt-srv-14-01 (127.0.1.1) port 10080 (#0)
> GET /abc/key HTTP/1.1
> User-Agent: curl/7.35.0
> Host: ubt-srv-14-01:10080
> Accept: */*
> 
< HTTP/1.1 404 Not Found
* Server Apache-Coyote/1.1 is not blacklisted
< Server: Apache-Coyote/1.1
< Content-Length: 0
< Date: Tue, 13 Oct 2015 13:52:20 GMT

Debug has been enabled on logging yet nothing is showing in the redirect 
in the access log.

However - logs do appear for curl -X GET 
http://ubt-srv-14-01:10080/audit-management-ds-1.0/info 

Any ideas?

Regards,

Theo

-
The Mileage Company Limited is a limited company registered in England under 
company number 2260073 whose registered office address is at
Astral Towers, Betts Way, London Road, Crawley, West Sussex, RH10 9XY.

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify the 
system manager.

This footnote also confirms that this email message has been swept by Mimecast 
for the presence of computer viruses. 
-

Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

George,

On 10/9/15 12:46 PM, George Stanchev wrote:
> One more clarification: on point [6] below I stated that Java is
> able to recover with a retry on a cached connection. Unfortunately
> that is only valid for higher level classes like HttpUrlConnection
> which makes 1 retry on IOException (and only on a GET and some
> other conditions). The lower-level sockets just throw and that’s
> it...

Can you confirm whether using SSLv2Hello also solves the problem? Or
do you have a requirement that nothing less than TLSv1 may even
handshake properly?

- -chris

> -Original Message- From: George Stanchev
> [mailto:gstanc...@serena.com] Sent: Friday, October 09, 2015 10:40
> AM To: Tomcat Users List Subject: RE: [OT] Tomcat 7.0.55/Jre 7u67:
> SEND TLSv1 ALERT: fatal, description = bad_record_mac
> 
> Just for the record, https.protocols is a property used by the
> HttpsUrlConnection class. If your app is using a client that
> doesn't rely on the internal Oracle HTTP client, it's better to use
> " jdk.tls.client.protocols" which is read directly by the
> socket/SSL classes. Apache Http Client is one client that does use
> sockets directly instead of HttpsUrlConnection.
> 
> 
> Also, I want to mention that we have finally been able to isolate a
> really nasty problem with Java SSL implementation and Windows's
> SSPI based SChannel acting as a server. The issue we ran into is
> very similar as to what the OP reported, that’s why I asked him a
> while ago on a separate thread about keystores if the server is
> IIS-based. The issue that we ran into might sound esoteric but our
> product ran into it very often. We have a configuration where we
> lock our intracomponent communication via 2way SSL. We have Java
> Tomcat-based server components that talk to IIS based native
> components via web services over HTTP which we secure with 2way
> SSL. When we upgraded to JRE 8 we started getting those connection
> resets in Tomcat when we enabled the 2way SSL. Those were on the
> Java->IIS calls that work over regular SSL. On the java side, if
> you turn on the ssl debug on, you'd see connection reset
> IOException thrown, and on the Windows side, you'd see " The
> following fatal alert was generated: 20. The internal error state
> is 960." In the System event log. This error is "
> TLS1_ALERT_BAD_RECORD_MAC" from SSPI. A search in Oracle's bug
> database found a close resemblance to this issue:
> https://bugs.openjdk.java.net/browse/JDK-8068812. But the reporter
> couldn't reproduce it and also was against another Oracle component
> Java Web Download or something like this. So we started working
> with Oracle but the intermittent and hard-to-reproduce nature of
> this issue hampered the investigation. As the OP mentioned below,
> there are apocryphal reports for this all over the web but people
> cannot troubleshoot it very well. Anyway here are my findings. In
> order for the issue to arise all those conditions must be met:
> 
> [1] The client must start with ClientHello TLSv1.2 [2] The server
> must respond with ServerHello TLSv1 (so the server should not have
> TLS1.2 enabled) [3] The cipher key exchange must NOT be ECDHE. I
> have not tried DHE as I could not make Windows take it. According
> to this doc [1] it should have several DHE key exchange ciphers
> available but I could not make it work. RSA key exchange exhibits
> the issue. I have been using “TLS_RSA_WITH_AES_256_CBC_SHA” to
> reproduce. [4] The initial connection must not be 2way-SSL [5] The
> server must upgrade the connection after encrypted payload is read.
> In case of IIS, it has 2way SSL setting on a Virtual Directory. The
> initial handshake is not 2way SSL, once the HTTP request is read,
> it determines that the requested resource (/gsoap) is 2way
> SSL-protected and upgrades the connection to 2way SSL. [6] The
> server must kill the connection abruptly when error happens. This
> is important as if the server terminates the connection gracefully
> and keeps it around Java is able to recover since it reuses the
> cached connection. IIS does exactly this. [7] The server must be
> Windows 7, Win2k8, Win2k8-R2, Win8. Might be other versions
> affected but bug is not evident on Win2k12 or Win2k12-R2 or Win10.
> Perhaps it was fixed, perhaps those versions support TLSv1.2
> 
> It might sound complicated but it is not, it is very common. All
> you have to do is to have a Virtual Directory in IIS that requires
> 2way SSL and is set to "want". RSA-based key exchanges are one of
> the most commonly used ciphers. The Windows platforms we tested
> with are still widely used in the enterprises while the adoption
> rate of win2k12+ is still lagging (from our experience with our
> customers). And you have equal "chance" of cipher support between
> Windows servers and Java 8 clients to land on RSA based cipher
> (which exhibits the issue) or ECDHE key exchange that is ok. Again,
> it might sound too complicated 

Issue with Tomcat Version 7.0.64

[kasturi]

Hi,

 

We have recently upgraded Tomcat to 7.0.64 from 7.0.59. Our application
extends SingleSignOn.java of catalina.jar to create a wrapper around it.
Some methods in the SingleSignOn.java class has been deprecated because of
which the compilation is failing. Details shared below.

 

 


Catalina 7.0.59

Catalina 7.0.64


 

//SingleSingOn Class

 

 

protected Map reverse = new HashMap();

 

 

public void sessionEvent(SessionEvent event)

  {

if (!getState().isAvailable()) {

  return;

}

if ((!"destroySession".equals(event.getType())) &&
(!"passivateSession".equals(event.getType( {

  return;

}

Session session = event.getSession();

if (this.containerLog.isDebugEnabled()) {

  this.containerLog.debug("Process session destroyed on " + session);

}

String ssoId = null;

synchronized (this.reverse)

{

  ssoId = (String)this.reverse.get(session);

}

if (ssoId == null) {

  return;

}

if (((session.getMaxInactiveInterval() > 0) &&
(System.currentTimeMillis() - session.getThisAccessedTimeInternal() >=
session.getMaxInactiveInterval() * 1000)) ||
("passivateSession".equals(event.getType())) ||
(!session.getManager().getContainer().getState().isAvailable())) {

  removeSession(ssoId, session);

} else {

  deregister(ssoId);

}

  }

 

 

 

 

//SingleSingOn Class

 

Reverse Map does not exist

 

sessionEvent() Method does not exist

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

This new class has been introduced, but we cannot extend this class as we
are already extending "SingleSignOn" class. 

 

Also, to instantiate this class "SSOID" is required, as its constructor
expects it. We are not sure what to pass here to instantiate it.

 

 

//SingleSignOnListener

 

public void sessionEvent(SessionEvent event)

  {

if (!"destroySession".equals(event.getType())) {

  return;

}

Session session = event.getSession();

Manager manager = session.getManager();

if (manager == null) {

  return;

}

Context context = (Context)manager.getContainer();

if (context == null) {

  return;

}

Authenticator authenticator = context.getAuthenticator();

if (!(authenticator instanceof AuthenticatorBase)) {

  return;

}

SingleSignOn sso = ((AuthenticatorBase)authenticator).sso;

if (sso == null) {

  return;

}

sso.sessionDestroyed(this.ssoId, session);

  }

}

 

 

 

 

 

//Our Code

 

public class CiscoSSOValve extends SingleSignOn   >> Extending Catalina
Class

{

 

public void sessionEvent(SessionEvent event) {

 

if(sNumTokens == 0) {

super.sessionEvent(event);>>
Overloading sessionEvent which does not exists in new Jar.

return;

}

 

// We only care about session destroyed events

if (!Session.SESSION_DESTROYED_EVENT.equals(event.getType())

&&
(!Session.SESSION_PASSIVATED_EVENT.equals(event.getType({

super.sessionEvent(event);

return;

}

 

 

Compilation Error

 

@

"ucxn_build_stash.pl.log" [noeol] 20853L, 2963854C
1,1   Top

[javac]   symbol:   variable reverse

[javac]   location: class CiscoSSOValve

[javac]
/auto/ipcbu-ucxn-cache/CORES/BLD-cc_mainline_16-cct-ccm-d/unityconnection/CL
NX_11.5.0.98/source/un_CUSA/Projects/cisco-unity-valve/src/com/cisco/unity/t
omcat/valve/CiscoSSOValve.java:98: error: cannot find symbol

[javac] super.sessionEvent(event); 

[javac]  ^

[javac]   symbol: method sessionEvent(SessionEvent)

[javac]
/auto/ipcbu-ucxn-cache/CORES/BLD-cc_mainline_16-cct-ccm-d/unityconnection/CL
NX_11.5.0.98/source/un_CUSA/Projects/cisco-unity-valve/src/com/cisco/unity/t
omcat/valve/CiscoSSOValve.java:100: error: cannot find symbol

[javac] if(null != lookup(ssoId)) { 

[javac]^

[javac]   symbol:   method lookup(String)

[javac]   location: class CiscoSSOValve

[javac]
/auto/ipcbu-ucxn-cache/CORES/BLD-cc_mainline_16-cct-ccm-d/unityconnection/CL
NX_11.5.0.98/source/un_CUSA/Projects/cisco-unity-valve/src/com/cisco/unity/t
omcat/valve/CiscoSSOValve.java:149: error: associate(String,Session) in
CiscoSSOValve cannot override associate(String,Session) in SingleSignOn

[javac] protected void associate(String ssoId, Session session) {

[javac]^

[javac]   return type void is not compatible with boolean

[javac] 7 errors

 

 

 

We need assistance on below points:

1.   How to fetch the SSOId corresponding to a session as 'reverse' map
does not exists any more.

2.   How does the call flow happen of SingleSignOn methods? 

 

 

Thanks and regards,

Kasturi.

Re: questions about tomcat 7 executor with rest services

[Brian Millett]

Thanks

> On Oct 12, 2015, at 5:01 PM, Mark Thomas  wrote:
> 
> On 12 October 2015 21:26:30 BST, Brian Millett  wrote:
>> I’m looking for some insight / info into using executor thread pool for
>> a tomcat 7 server that handles many REST services.   
>> Wondering if a large maxThreads in an Executor would have better
>> through put than the same maxThreads for a normal connector?
> 
> Nope. Internally the Connector uses an executor.
> 
>> What scenario would encourage the use of an Executor over a normal
>> connector? 
> 
> Sharing a common thread pool between multiple connectors. Usually when you 
> want to limit concurrent requests across http and http. 
> 
> Mark
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Unable to deploy app with Tomcat Manager Text interface using a Context Descriptor

[Mark Thomas]

On 13/10/2015 16:09, ptruche wrote:
> My application context is defined as an XML file located in 
> `my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml`.
> name='my_config_dir' value='/my/path/to/myApp' type='java.lang.String'/>
> 
> `/my/path/to/myApp` contains the WAR file myAppWarFile.war and a number of 
> externalized properties that are read by Spring.
> Tomcat is configured with autoDeploy turned off. When I start Tomcat, it 
> creates `my/path/to/Tomcat/conf/webapps/my-app/` and the WAR file gets 
> unpacked into this location as expected, and the application of course can 
> run as expected.
> When I want to deploy a new version without restarting Tomcat, I run the 
> undeploy command as follows:
> curl http://localhost:8080/manager/text/undeploy?path=/my-app --user 
> my-username:my-password
> ... and that works. But when I instruct Tomcat to deploy with the following 
> curl statement, I get a failure.
> curl 
> http://localhost:8080/manager/text/deploy?config=file:/my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml
>  --user my-username:my-password# Tomcat responseFAIL - Invalid 
> context path null was specified
> Adding the path does not help much, I still get a failure.
> curl 
> http://localhost:8080/manager/text/deploy?config=file:/my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml\=/my-app
>  --user my-username:my-password
> # Tomcat responseFAIL - Failed to deploy application at context path 
> /my-app
> The worst part is that tailing catalina.out does not yield any insight. And 
> on top of that, Tomcat deletes the application context XML file 
> `my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml`!
> Naturally I have reviewed Tomcat documentation 
> (https://tomcat.apache.org/tomcat-8.0-doc/manager-howto.html#Deploy_using_a_Context_configuration_%22.xml%22_file)
>  and I have googled all day to figure this out, but I have not found anything 
> that can help me with this particular configuration.
> It feels as though the choice is: 
>  1. Tomcat with autoDeploy on (not recommended for production) in which case 
> simply dropping the new WAR to `/my/path/to/myApp/` will cause Tomcat to hot 
> deploy the app. 2. Tomcat with autoDeploy off, but re-deploying requires a 
> Tomcat restart because the deploy API does not seem to be working as 
> advertised.
> Has anybody made this work with this configuration?
> ADDITIONAL INFORMATION
> I turned up the logging on Catalina. When I run the first deploy command 
> without the path, I get this set of log entries:
> FINE: Start processing with input 
> [config=file:/my/path/to/tomcat/conf/Catalina/localhost/my-app.xml]Oct 
> 13, 2015 10:04:53 AM 
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler processFINE: 
> Socket: 
> [org.apache.tomcat.util.net.SocketWrapper@189651c1:Socket[addr=/0:0:0:0:0:0:0:1,port=45415,localport=8080]],
>  Status in: [OPEN_READ], State out: [OPEN]Oct 13, 2015 10:04:53 AM 
> org.apache.coyote.http11.AbstractHttp11Processor processFINE: Error 
> parsing HTTP request headerjava.io.EOFException: Unexpected EOF read on 
> the socketat 
> org.apache.coyote.http11.Http11Processor.setRequestLineReadTimeout(Http11Processor.java:168)
> at 
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:982)
> at 
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611)
> at 
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
> at java.util.concurrent.Thread
 P
oolExecutor.runWorker(ThreadPoolExecutor.java:1145)at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
   at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:744)
> Oct 13, 2015 10:04:53 AM 
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler processFINE: 
> Socket: 
> [org.apache.tomcat.util.net.SocketWrapper@189651c1:Socket[addr=/0:0:0:0:0:0:0:1,port=45415,localport=8080]],
>  Status in: [OPEN_READ], State out: [CLOSED]Oct 13, 2015 10:04:53 AM 
> org.apache.tomcat.util.threads.LimitLatch countDownFINE: Counting 
> down[http-bio-8080-exec-16] latch=1
> SERVER CONFIG
>  Apache Tomcat 7.0.55 (but confirmed same problem with 7.0.59 and 8.0.12. 
> Tomcat configured to run as a service with tomcat user and group owning the 
> catalina base and subfolders, and the docBase folders outside of the appBase 
> Centos 6.5
> 

The above is pretty much unreadable. Can you reformat please.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Unable to deploy app with Tomcat Manager Text interface using a Context Descriptor

[ptruche]

Sorry about the formatting issue. Here is the corrected 
version.---

My application context is defined as an XML file located in 
`my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml`.

    
   
    

`/my/path/to/myApp` contains the WAR file myAppWarFile.war and a number of 
externalized properties that are read by Spring.

Tomcat is configured with autoDeploy turned off. When I start Tomcat, it 
creates `my/path/to/Tomcat/conf/webapps/my-app/` and the WAR file gets unpacked 
into this location as expected, and the application of course can run as 
expected.

When I want to deploy a new version without restarting Tomcat, I run the 
undeploy command as follows:

    curl http://localhost:8080/manager/text/undeploy?path=/my-app --user 
my-username:my-password

... and that works. But when I instruct Tomcat to deploy with the following 
curl statement, I get a failure.

    curl 
http://localhost:8080/manager/text/deploy?config=file:/my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml
 --user my-username:my-password
    # Tomcat response
    FAIL - Invalid context path null was specified

Adding the path does not help much, I still get a failure.

    curl 
http://localhost:8080/manager/text/deploy?config=file:/my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml\=/my-app
 --user my-username:my-password

    # Tomcat response
    FAIL - Failed to deploy application at context path /my-app

The worst part is that tailing catalina.out does not yield any insight. And on 
top of that, Tomcat deletes the application context XML file 
`my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml`!

Naturally I have reviewed Tomcat documentation 
(https://tomcat.apache.org/tomcat-8.0-doc/manager-howto.html#Deploy_using_a_Context_configuration_%22.xml%22_file)
 and I have googled all day to figure this out, but I have not found anything 
that can help me with this particular configuration.

It feels as though the choice is: 

 1. Tomcat with autoDeploy on (not recommended for production) in which case 
simply dropping the new WAR to `/my/path/to/myApp/` will cause Tomcat to hot 
deploy the app.
 2. Tomcat with autoDeploy off, but re-deploying requires a Tomcat restart 
because the deploy API does not seem to be working as advertised.

Has anybody made this work with this configuration?

ADDITIONAL INFORMATION

I turned up the logging on Catalina. When I run the first deploy command 
without the path, I get this set of log entries:

    FINE: Start processing with input 
[config=file:/my/path/to/tomcat/conf/Catalina/localhost/my-app.xml]
    Oct 13, 2015 10:04:53 AM 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler process
    FINE: Socket: 
[org.apache.tomcat.util.net.SocketWrapper@189651c1:Socket[addr=/0:0:0:0:0:0:0:1,port=45415,localport=8080]],
 Status in: [OPEN_READ], State out: [OPEN]
    Oct 13, 2015 10:04:53 AM org.apache.coyote.http11.AbstractHttp11Processor 
process
    FINE: Error parsing HTTP request header
    java.io.EOFException: Unexpected EOF read on the socket
    at 
org.apache.coyote.http11.Http11Processor.setRequestLineReadTimeout(Http11Processor.java:168)
    at 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:982)
    at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611)
    at 
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
    at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    at java.lang.Thread.run(Thread.java:744)

    Oct 13, 2015 10:04:53 AM 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler process
    FINE: Socket: 
[org.apache.tomcat.util.net.SocketWrapper@189651c1:Socket[addr=/0:0:0:0:0:0:0:1,port=45415,localport=8080]],
 Status in: [OPEN_READ], State out: [CLOSED]
    Oct 13, 2015 10:04:53 AM org.apache.tomcat.util.threads.LimitLatch countDown
    FINE: Counting down[http-bio-8080-exec-16] latch=1

SERVER CONFIG

    Apache Tomcat 7.0.55 (but confirmed same problem with 7.0.59 and 8.0.12.
    Tomcat configured to run as a service with tomcat user and group owning the 
catalina base and subfolders, and the docBase folders outside of the appBase
    Centos 6.5  From: Mark Thomas 
 To: Tomcat Users List  
 Sent: Tuesday, October 13, 2015 11:20 AM
 Subject: Re: Unable to deploy app with Tomcat Manager Text interface using a 
Context Descriptor
   
On 13/10/2015 16:09, ptruche wrote:


> My application context is defined as an XML file located in 
> `my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml`.
>          name='my_config_dir' value='/my/path/to/myApp' 

Unable to deploy app with Tomcat Manager Text interface using a Context Descriptor

[ptruche]

My application context is defined as an XML file located in 
`my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml`.
               

`/my/path/to/myApp` contains the WAR file myAppWarFile.war and a number of 
externalized properties that are read by Spring.
Tomcat is configured with autoDeploy turned off. When I start Tomcat, it 
creates `my/path/to/Tomcat/conf/webapps/my-app/` and the WAR file gets unpacked 
into this location as expected, and the application of course can run as 
expected.
When I want to deploy a new version without restarting Tomcat, I run the 
undeploy command as follows:
    curl http://localhost:8080/manager/text/undeploy?path=/my-app --user 
my-username:my-password
... and that works. But when I instruct Tomcat to deploy with the following 
curl statement, I get a failure.
    curl 
http://localhost:8080/manager/text/deploy?config=file:/my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml
 --user my-username:my-password    # Tomcat response    FAIL - Invalid context 
path null was specified
Adding the path does not help much, I still get a failure.
    curl 
http://localhost:8080/manager/text/deploy?config=file:/my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml\=/my-app
 --user my-username:my-password
    # Tomcat response    FAIL - Failed to deploy application at context path 
/my-app
The worst part is that tailing catalina.out does not yield any insight. And on 
top of that, Tomcat deletes the application context XML file 
`my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml`!
Naturally I have reviewed Tomcat documentation 
(https://tomcat.apache.org/tomcat-8.0-doc/manager-howto.html#Deploy_using_a_Context_configuration_%22.xml%22_file)
 and I have googled all day to figure this out, but I have not found anything 
that can help me with this particular configuration.
It feels as though the choice is: 
 1. Tomcat with autoDeploy on (not recommended for production) in which case 
simply dropping the new WAR to `/my/path/to/myApp/` will cause Tomcat to hot 
deploy the app. 2. Tomcat with autoDeploy off, but re-deploying requires a 
Tomcat restart because the deploy API does not seem to be working as advertised.
Has anybody made this work with this configuration?
ADDITIONAL INFORMATION
I turned up the logging on Catalina. When I run the first deploy command 
without the path, I get this set of log entries:
    FINE: Start processing with input 
[config=file:/my/path/to/tomcat/conf/Catalina/localhost/my-app.xml]    Oct 13, 
2015 10:04:53 AM org.apache.coyote.AbstractProtocol$AbstractConnectionHandler 
process    FINE: Socket: 
[org.apache.tomcat.util.net.SocketWrapper@189651c1:Socket[addr=/0:0:0:0:0:0:0:1,port=45415,localport=8080]],
 Status in: [OPEN_READ], State out: [OPEN]    Oct 13, 2015 10:04:53 AM 
org.apache.coyote.http11.AbstractHttp11Processor process    FINE: Error parsing 
HTTP request header    java.io.EOFException: Unexpected EOF read on the socket  
      at 
org.apache.coyote.http11.Http11Processor.setRequestLineReadTimeout(Http11Processor.java:168)
        at 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:982)
        at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611)
        at 
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
        at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 
       at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
       at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
        at java.lang.Thread.run(Thread.java:744)
    Oct 13, 2015 10:04:53 AM 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler process    FINE: 
Socket: 
[org.apache.tomcat.util.net.SocketWrapper@189651c1:Socket[addr=/0:0:0:0:0:0:0:1,port=45415,localport=8080]],
 Status in: [OPEN_READ], State out: [CLOSED]    Oct 13, 2015 10:04:53 AM 
org.apache.tomcat.util.threads.LimitLatch countDown    FINE: Counting 
down[http-bio-8080-exec-16] latch=1
SERVER CONFIG
 Apache Tomcat 7.0.55 (but confirmed same problem with 7.0.59 and 8.0.12. 
Tomcat configured to run as a service with tomcat user and group owning the 
catalina base and subfolders, and the docBase folders outside of the appBase 
Centos 6.5

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

[George Stanchev]

Hi Chris,

How do you force Java 8 to use SSLv2Hello? So far I am unable to force it to go 
down to use SSLv2Hello. It would've been nice to be able to control the first 
handshake message version (TLSv1 or TLSv1.2 or SSLv2Hello), but I have not been 
able to do that...

George

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Tuesday, October 13, 2015 7:42 AM
To: Tomcat Users List
Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

George,

On 10/9/15 12:46 PM, George Stanchev wrote:
> One more clarification: on point [6] below I stated that Java is able 
> to recover with a retry on a cached connection. Unfortunately that is 
> only valid for higher level classes like HttpUrlConnection which makes 
> 1 retry on IOException (and only on a GET and some other conditions). 
> The lower-level sockets just throw and that’s it...

Can you confirm whether using SSLv2Hello also solves the problem? Or do you 
have a requirement that nothing less than TLSv1 may even handshake properly?

- -chris

> -Original Message- From: George Stanchev 
> [mailto:gstanc...@serena.com] Sent: Friday, October 09, 2015 10:40 AM 
> To: Tomcat Users List Subject: RE: [OT] Tomcat 7.0.55/Jre 7u67:
> SEND TLSv1 ALERT: fatal, description = bad_record_mac
> 
> Just for the record, https.protocols is a property used by the 
> HttpsUrlConnection class. If your app is using a client that doesn't 
> rely on the internal Oracle HTTP client, it's better to use " 
> jdk.tls.client.protocols" which is read directly by the socket/SSL 
> classes. Apache Http Client is one client that does use sockets 
> directly instead of HttpsUrlConnection.
> 
> 
> Also, I want to mention that we have finally been able to isolate a 
> really nasty problem with Java SSL implementation and Windows's SSPI 
> based SChannel acting as a server. The issue we ran into is very 
> similar as to what the OP reported, that’s why I asked him a while ago 
> on a separate thread about keystores if the server is IIS-based. The 
> issue that we ran into might sound esoteric but our product ran into 
> it very often. We have a configuration where we lock our 
> intracomponent communication via 2way SSL. We have Java Tomcat-based 
> server components that talk to IIS based native components via web 
> services over HTTP which we secure with 2way SSL. When we upgraded to 
> JRE 8 we started getting those connection resets in Tomcat when we 
> enabled the 2way SSL. Those were on the
> Java->IIS calls that work over regular SSL. On the java side, if
> you turn on the ssl debug on, you'd see connection reset IOException 
> thrown, and on the Windows side, you'd see " The following fatal alert 
> was generated: 20. The internal error state is 960." In the System 
> event log. This error is "
> TLS1_ALERT_BAD_RECORD_MAC" from SSPI. A search in Oracle's bug 
> database found a close resemblance to this issue:
> https://bugs.openjdk.java.net/browse/JDK-8068812. But the reporter 
> couldn't reproduce it and also was against another Oracle component 
> Java Web Download or something like this. So we started working with 
> Oracle but the intermittent and hard-to-reproduce nature of this issue 
> hampered the investigation. As the OP mentioned below, there are 
> apocryphal reports for this all over the web but people cannot 
> troubleshoot it very well. Anyway here are my findings. In order for 
> the issue to arise all those conditions must be met:
> 
> [1] The client must start with ClientHello TLSv1.2 [2] The server must 
> respond with ServerHello TLSv1 (so the server should not have
> TLS1.2 enabled) [3] The cipher key exchange must NOT be ECDHE. I have 
> not tried DHE as I could not make Windows take it. According to this 
> doc [1] it should have several DHE key exchange ciphers available but 
> I could not make it work. RSA key exchange exhibits the issue. I have 
> been using “TLS_RSA_WITH_AES_256_CBC_SHA” to reproduce. [4] The 
> initial connection must not be 2way-SSL [5] The server must upgrade 
> the connection after encrypted payload is read.
> In case of IIS, it has 2way SSL setting on a Virtual Directory. The 
> initial handshake is not 2way SSL, once the HTTP request is read, it 
> determines that the requested resource (/gsoap) is 2way SSL-protected 
> and upgrades the connection to 2way SSL. [6] The server must kill the 
> connection abruptly when error happens. This is important as if the 
> server terminates the connection gracefully and keeps it around Java 
> is able to recover since it reuses the cached connection. IIS does 
> exactly this. [7] The server must be Windows 7, Win2k8, Win2k8-R2, 
> Win8. Might be other versions affected but bug is not evident on 
> Win2k12 or Win2k12-R2 or Win10.
> Perhaps it was fixed, perhaps those versions support TLSv1.2
> 
> It might sound complicated but it is not, it is very 

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

[George Stanchev]

Hi Chris,

[1] states: " JDK 7-9 enables SSLv2Hello on the server side only.  (Will not 
send, but will accept SSLv2Hellos)"

I've opened support case both MS and already there is a bug filed with Oracle 
on this and really, to be absolutely certain if the issue is in Java or 
SChannel, one would have to write a non-Java client that that mimics the 
handshake messages send from Java with something like OpenSSL or NSS or 
whatever and see if the bug replicates. Writing a Java/Java server client could 
still leave some doubts as one can argue the code reuse could mask the problem 
- it works but the bug on the client side is hidden by the server containing 
similar/same bug so the MACs check out...

Unfortunately I don't have the time to invest in this more than I already had. 
And if MS support engineers can pass it on to someone from the windows core 
team may be we can have some movement forward. 

George


[1] 
http://www.oracle.com/technetwork/java/javase/documentation/cve-2014-3566-2342133.html

-Original Message-
From: George Stanchev [mailto:gstanc...@serena.com] 
Sent: Tuesday, October 13, 2015 10:26 AM
To: Tomcat Users List
Subject: RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

Hi Chris,

How do you force Java 8 to use SSLv2Hello? So far I am unable to force it to go 
down to use SSLv2Hello. It would've been nice to be able to control the first 
handshake message version (TLSv1 or TLSv1.2 or SSLv2Hello), but I have not been 
able to do that...

George

-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Tuesday, October 13, 2015 7:42 AM
To: Tomcat Users List
Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

George,

On 10/9/15 12:46 PM, George Stanchev wrote:
> One more clarification: on point [6] below I stated that Java is able 
> to recover with a retry on a cached connection. Unfortunately that is 
> only valid for higher level classes like HttpUrlConnection which makes
> 1 retry on IOException (and only on a GET and some other conditions). 
> The lower-level sockets just throw and that’s it...

Can you confirm whether using SSLv2Hello also solves the problem? Or do you 
have a requirement that nothing less than TLSv1 may even handshake properly?

- -chris

> -Original Message- From: George Stanchev 
> [mailto:gstanc...@serena.com] Sent: Friday, October 09, 2015 10:40 AM
> To: Tomcat Users List Subject: RE: [OT] Tomcat 7.0.55/Jre 7u67:
> SEND TLSv1 ALERT: fatal, description = bad_record_mac
> 
> Just for the record, https.protocols is a property used by the 
> HttpsUrlConnection class. If your app is using a client that doesn't 
> rely on the internal Oracle HTTP client, it's better to use "
> jdk.tls.client.protocols" which is read directly by the socket/SSL 
> classes. Apache Http Client is one client that does use sockets 
> directly instead of HttpsUrlConnection.
> 
> 
> Also, I want to mention that we have finally been able to isolate a 
> really nasty problem with Java SSL implementation and Windows's SSPI 
> based SChannel acting as a server. The issue we ran into is very 
> similar as to what the OP reported, that’s why I asked him a while ago 
> on a separate thread about keystores if the server is IIS-based. The 
> issue that we ran into might sound esoteric but our product ran into 
> it very often. We have a configuration where we lock our 
> intracomponent communication via 2way SSL. We have Java Tomcat-based 
> server components that talk to IIS based native components via web 
> services over HTTP which we secure with 2way SSL. When we upgraded to 
> JRE 8 we started getting those connection resets in Tomcat when we 
> enabled the 2way SSL. Those were on the
> Java->IIS calls that work over regular SSL. On the java side, if
> you turn on the ssl debug on, you'd see connection reset IOException 
> thrown, and on the Windows side, you'd see " The following fatal alert 
> was generated: 20. The internal error state is 960." In the System 
> event log. This error is "
> TLS1_ALERT_BAD_RECORD_MAC" from SSPI. A search in Oracle's bug 
> database found a close resemblance to this issue:
> https://bugs.openjdk.java.net/browse/JDK-8068812. But the reporter 
> couldn't reproduce it and also was against another Oracle component 
> Java Web Download or something like this. So we started working with 
> Oracle but the intermittent and hard-to-reproduce nature of this issue 
> hampered the investigation. As the OP mentioned below, there are 
> apocryphal reports for this all over the web but people cannot 
> troubleshoot it very well. Anyway here are my findings. In order for 
> the issue to arise all those conditions must be met:
> 
> [1] The client must start with ClientHello TLSv1.2 [2] The server must 
> respond with ServerHello TLSv1 (so the server should not have
> TLS1.2 enabled) [3] The 

Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

George,

On 10/13/15 12:35 PM, George Stanchev wrote:
> [1] states: " JDK 7-9 enables SSLv2Hello on the server side only. 
> (Will not send, but will accept SSLv2Hellos)"

Interesting. This absolutely makes sense, though, since SSL should
just die. :)

> I've opened support case both MS and already there is a bug filed 
> with Oracle on this and really, to be absolutely certain if the
> issue is in Java or SChannel, one would have to write a non-Java
> client that that mimics the handshake messages send from Java with
> something like OpenSSL or NSS or whatever and see if the bug
> replicates.

It might be doable with OpenSSL s_client or something. Tough to
replicate Java's behavior with a non-Java tool, though.

> Writing a Java/Java server client could still leave some doubts as 
> one can argue the code reuse could mask the problem - it works but 
> the bug on the client side is hidden by the server containing 
> similar/same bug so the MACs check out...
> 
> Unfortunately I don't have the time to invest in this more than I 
> already had. And if MS support engineers can pass it on to someone 
> from the windows core team may be we can have some movement
> forward.

Okay. Thanks for your work so far.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWHWNuAAoJEBzwKT+lPKRYgWAP/A8fUJ5Dzu+O46GNWpdobqq0
7ugkb2cQ1VM92Q+22Wtl87GSRPhBS8jwNrBBCJmoyBjRZ/LKVcwtcWLzUIBllXm5
t8iorXpQxaps1G0AEEf5tAwHXyN75J2vC9qvRvD6dkekHXHwO3RRqvSCqQjEjeVJ
XsOdjuIhPwX0B0SN8Apdshvxe98sC9QPn73LNdSM9+j8Ob1vCDHDiMFj60K72Su1
E0UmPYEJdhb5D+PvSM/7CMcAlkJYmCl8VlNFWD320ymjObfIMymfOk+kqKLqVItQ
+r2e20At1qCyeyg2Gcxb4X1ajIhcxdgP7WJYtg57Pwrp4ZVZ6d7RM+CIqt28SfxT
EtTamDZ8aPYsCKqMWIYRPyLrWaouEuLJEmzweF8B+NxY0svK8vEOiro/vR4LycOZ
PG5zxuS/QMJR2oEgkeUz9+NhB8nP/qJxMhc40pKGmvZxC7ljM/tP7jTvE1MwmMHE
P8rX5b3yF8DfMdGZdIlrHJ8wXYSzJdTMJvA5ffXVKaObGMYtAFFDlfupud1iO9ML
Hh4exxX+/NU7fXt+ot6BLEFAfDD9+z6uOeq+vK6bxaITubFVGIavhowjAgQIBNt3
O//p9dJQVKan0db9kqyLpLMrrFYd/cmA8DZDxoY/iaVuoKhJ6blbDMQKi2DlsvgF
WGDHUsSBZIYTFq5mc7VO
=eyUN
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Issue with Tomcat Version 7.0.64

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Kasturi,

On 10/13/15 9:59 AM, kasturi wrote:
> We have recently upgraded Tomcat to 7.0.64 from 7.0.59. Our
> application extends SingleSignOn.java of catalina.jar to create a
> wrapper around it. Some methods in the SingleSignOn.java class has
> been deprecated because of which the compilation is failing.
> Details shared below.
> 
> Catalina 7.0.59
> 
> Catalina 7.0.64

The list has ruined your formatting. Can you post with a text-only
message?

> //SingleSingOn Class
> 
> protected Map reverse = new HashMap();
> 
> public void sessionEvent(SessionEvent event)
> 
> {
> 
> if (!getState().isAvailable()) {
> 
> return;
> 
> }
> 
> if ((!"destroySession".equals(event.getType())) && 
> (!"passivateSession".equals(event.getType( {
> 
> return;
> 
> }
> 
> Session session = event.getSession();
> 
> if (this.containerLog.isDebugEnabled()) {
> 
> this.containerLog.debug("Process session destroyed on " +
> session);
> 
> }
> 
> String ssoId = null;
> 
> synchronized (this.reverse)
> 
> {
> 
> ssoId = (String)this.reverse.get(session);
> 
> }
> 
> if (ssoId == null) {
> 
> return;
> 
> }
> 
> if (((session.getMaxInactiveInterval() > 0) && 
> (System.currentTimeMillis() - session.getThisAccessedTimeInternal()
> >= session.getMaxInactiveInterval() * 1000)) || 
> ("passivateSession".equals(event.getType())) || 
> (!session.getManager().getContainer().getState().isAvailable())) {
> 
> removeSession(ssoId, session);
> 
> } else {
> 
> deregister(ssoId);
> 
> }
> 
> }
> 
> 
> 
> 
> 
> 
> 
> 
> 
> //SingleSingOn Class
> 
> 
> 
> Reverse Map does not exist

That doesn't look like a compiler message.

> sessionEvent() Method does not exist

Nor does this. Can you post actual compiler output?

> This new class has been introduced, but we cannot extend this class
> as we are already extending "SingleSignOn" class.

What new class?

> Also, to instantiate this class "SSOID" is required, as its
> constructor expects it. We are not sure what to pass here to
> instantiate it.

Which class requires SSOID to instantiate it? This class has a no-arg
constructor in 7.0.64:

http://svn.apache.org/viewvc/tomcat/tc7.0.x/tags/TOMCAT_7_0_64/java/org/
apache/catalina/authenticator/SingleSignOn.java?view=markup

> //SingleSignOnListener
> 
> 
> 
> public void sessionEvent(SessionEvent event)
> 
> {
> 
> if (!"destroySession".equals(event.getType())) {
> 
> return;
> 
> }
> 
> Session session = event.getSession();
> 
> Manager manager = session.getManager();
> 
> if (manager == null) {
> 
> return;
> 
> }
> 
> Context context = (Context)manager.getContainer();
> 
> if (context == null) {
> 
> return;
> 
> }
> 
> Authenticator authenticator = context.getAuthenticator();
> 
> if (!(authenticator instanceof AuthenticatorBase)) {
> 
> return;
> 
> }
> 
> SingleSignOn sso = ((AuthenticatorBase)authenticator).sso;
> 
> if (sso == null) {
> 
> return;
> 
> }
> 
> sso.sessionDestroyed(this.ssoId, session);
> 
> }
> 
> }
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> //Our Code
> 
> 
> 
> public class CiscoSSOValve extends SingleSignOn   >> Extending
> Catalina Class
> 
> {
> 
> 
> 
> public void sessionEvent(SessionEvent event) {
> 
> 
> 
> if(sNumTokens == 0) {
> 
> super.sessionEvent(event);>> 
> Overloading sessionEvent which does not exists in new Jar.
> 
> return;
> 
> }
> 
> 
> 
> // We only care about session destroyed events
> 
> if (!Session.SESSION_DESTROYED_EVENT.equals(event.getType())
> 
> && (!Session.SESSION_PASSIVATED_EVENT.equals(event.getType({
> 
> super.sessionEvent(event);
> 
> return;
> 
> }
> 
> 
> 
> 
> 
> Compilation Error
> 
> 
> 
> @
> 
> "ucxn_build_stash.pl.log" [noeol] 20853L, 2963854C 1,1
> Top
> 
> [javac]   symbol:   variable reverse
> 
> [javac]   location: class CiscoSSOValve
> 
> [javac] 
> /auto/ipcbu-ucxn-cache/CORES/BLD-cc_mainline_16-cct-ccm-d/unityconnect
ion/CL
>
> 
NX_11.5.0.98/source/un_CUSA/Projects/cisco-unity-valve/src/com/cisco/uni
ty/t
> omcat/valve/CiscoSSOValve.java:98: error: cannot find symbol
> 
> [javac] super.sessionEvent(event);
> 
> [javac]  ^
> 
> [javac]   symbol: method sessionEvent(SessionEvent)
> 
> [javac] 
> /auto/ipcbu-ucxn-cache/CORES/BLD-cc_mainline_16-cct-ccm-d/unityconnect
ion/CL
>
> 
NX_11.5.0.98/source/un_CUSA/Projects/cisco-unity-valve/src/com/cisco/uni
ty/t
> omcat/valve/CiscoSSOValve.java:100: error: cannot find symbol
> 
> [javac] if(null != lookup(ssoId)) {
> 
> [javac]^
> 
> [javac]   symbol:   method lookup(String)
> 
> [javac]   location: class CiscoSSOValve
> 
> [javac] 
> /auto/ipcbu-ucxn-cache/CORES/BLD-cc_mainline_16-cct-ccm-d/unityconnect
ion/CL
>
> 
NX_11.5.0.98/source/un_CUSA/Projects/cisco-unity-valve/src/com/cisco/uni
ty/t
> omcat/valve/CiscoSSOValve.java:149: error:
> associate(String,Session) in CiscoSSOValve cannot override
> associate(String,Session) in SingleSignOn
> 
> [javac] protected void associate(String 

Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

[Aurélien Terrestris]

George,

do you have any network capture that we can see ?

2015-10-13 22:10 GMT+02:00 George Stanchev :

> >> It might be doable with OpenSSL s_client or something. Tough to
> replicate Java's behavior with a non-Java tool, though.
>
> I tried hard with the s_client but it can limit the protocols to one or
> another but it canot mix-and-match (hello 1.2, ok we will do 1.0) like Java
> 8 does. Either TLSv1 or TLSv1.2 but not both. Neither can curl which is
> also on top of openssl.
>
> Today, I spent 2.5 hours with a lemming from MS getting basically nowhere.
> I really need an engineer, but they give me those clueless support people
> that is wasting mine and their time. If someone knows how to escalate or a
> forum where MS developers hang out, I would appreciate it. The support
> person I got today was clueless, went over a script and any attempt to
> explain a little more technical details led to total confusion and
> rebooting the script to beginning. Totally frustrating. At least with
> Oracle I got to talk with an actual engineer...
>
> George
>
>
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Tuesday, October 13, 2015 2:03 PM
> To: Tomcat Users List
> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal,
> description = bad_record_mac
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> George,
>
> On 10/13/15 12:35 PM, George Stanchev wrote:
> > [1] states: " JDK 7-9 enables SSLv2Hello on the server side only.
> > (Will not send, but will accept SSLv2Hellos)"
>
> Interesting. This absolutely makes sense, though, since SSL should just
> die. :)
>
> > I've opened support case both MS and already there is a bug filed with
> > Oracle on this and really, to be absolutely certain if the issue is in
> > Java or SChannel, one would have to write a non-Java client that that
> > mimics the handshake messages send from Java with something like
> > OpenSSL or NSS or whatever and see if the bug replicates.
>
> It might be doable with OpenSSL s_client or something. Tough to replicate
> Java's behavior with a non-Java tool, though.
>
> > Writing a Java/Java server client could still leave some doubts as one
> > can argue the code reuse could mask the problem - it works but the bug
> > on the client side is hidden by the server containing similar/same bug
> > so the MACs check out...
> >
> > Unfortunately I don't have the time to invest in this more than I
> > already had. And if MS support engineers can pass it on to someone
> > from the windows core team may be we can have some movement forward.
>
> Okay. Thanks for your work so far.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJWHWNuAAoJEBzwKT+lPKRYgWAP/A8fUJ5Dzu+O46GNWpdobqq0
> 7ugkb2cQ1VM92Q+22Wtl87GSRPhBS8jwNrBBCJmoyBjRZ/LKVcwtcWLzUIBllXm5
> t8iorXpQxaps1G0AEEf5tAwHXyN75J2vC9qvRvD6dkekHXHwO3RRqvSCqQjEjeVJ
> XsOdjuIhPwX0B0SN8Apdshvxe98sC9QPn73LNdSM9+j8Ob1vCDHDiMFj60K72Su1
> E0UmPYEJdhb5D+PvSM/7CMcAlkJYmCl8VlNFWD320ymjObfIMymfOk+kqKLqVItQ
> +r2e20At1qCyeyg2Gcxb4X1ajIhcxdgP7WJYtg57Pwrp4ZVZ6d7RM+CIqt28SfxT
> EtTamDZ8aPYsCKqMWIYRPyLrWaouEuLJEmzweF8B+NxY0svK8vEOiro/vR4LycOZ
> PG5zxuS/QMJR2oEgkeUz9+NhB8nP/qJxMhc40pKGmvZxC7ljM/tP7jTvE1MwmMHE
> P8rX5b3yF8DfMdGZdIlrHJ8wXYSzJdTMJvA5ffXVKaObGMYtAFFDlfupud1iO9ML
> Hh4exxX+/NU7fXt+ot6BLEFAfDD9+z6uOeq+vK6bxaITubFVGIavhowjAgQIBNt3
> O//p9dJQVKan0db9kqyLpLMrrFYd/cmA8DZDxoY/iaVuoKhJ6blbDMQKi2DlsvgF
> WGDHUsSBZIYTFq5mc7VO
> =eyUN
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

[George Stanchev]

>> It might be doable with OpenSSL s_client or something. Tough to replicate 
>> Java's behavior with a non-Java tool, though.

I tried hard with the s_client but it can limit the protocols to one or another 
but it canot mix-and-match (hello 1.2, ok we will do 1.0) like Java 8 does. 
Either TLSv1 or TLSv1.2 but not both. Neither can curl which is also on top of 
openssl.

Today, I spent 2.5 hours with a lemming from MS getting basically nowhere. I 
really need an engineer, but they give me those clueless support people that is 
wasting mine and their time. If someone knows how to escalate or a forum where 
MS developers hang out, I would appreciate it. The support person I got today 
was clueless, went over a script and any attempt to explain a little more 
technical details led to total confusion and rebooting the script to beginning. 
Totally frustrating. At least with Oracle I got to talk with an actual 
engineer...

George


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Tuesday, October 13, 2015 2:03 PM
To: Tomcat Users List
Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

George,

On 10/13/15 12:35 PM, George Stanchev wrote:
> [1] states: " JDK 7-9 enables SSLv2Hello on the server side only. 
> (Will not send, but will accept SSLv2Hellos)"

Interesting. This absolutely makes sense, though, since SSL should just die. :)

> I've opened support case both MS and already there is a bug filed with 
> Oracle on this and really, to be absolutely certain if the issue is in 
> Java or SChannel, one would have to write a non-Java client that that 
> mimics the handshake messages send from Java with something like 
> OpenSSL or NSS or whatever and see if the bug replicates.

It might be doable with OpenSSL s_client or something. Tough to replicate 
Java's behavior with a non-Java tool, though.

> Writing a Java/Java server client could still leave some doubts as one 
> can argue the code reuse could mask the problem - it works but the bug 
> on the client side is hidden by the server containing similar/same bug 
> so the MACs check out...
> 
> Unfortunately I don't have the time to invest in this more than I 
> already had. And if MS support engineers can pass it on to someone 
> from the windows core team may be we can have some movement forward.

Okay. Thanks for your work so far.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWHWNuAAoJEBzwKT+lPKRYgWAP/A8fUJ5Dzu+O46GNWpdobqq0
7ugkb2cQ1VM92Q+22Wtl87GSRPhBS8jwNrBBCJmoyBjRZ/LKVcwtcWLzUIBllXm5
t8iorXpQxaps1G0AEEf5tAwHXyN75J2vC9qvRvD6dkekHXHwO3RRqvSCqQjEjeVJ
XsOdjuIhPwX0B0SN8Apdshvxe98sC9QPn73LNdSM9+j8Ob1vCDHDiMFj60K72Su1
E0UmPYEJdhb5D+PvSM/7CMcAlkJYmCl8VlNFWD320ymjObfIMymfOk+kqKLqVItQ
+r2e20At1qCyeyg2Gcxb4X1ajIhcxdgP7WJYtg57Pwrp4ZVZ6d7RM+CIqt28SfxT
EtTamDZ8aPYsCKqMWIYRPyLrWaouEuLJEmzweF8B+NxY0svK8vEOiro/vR4LycOZ
PG5zxuS/QMJR2oEgkeUz9+NhB8nP/qJxMhc40pKGmvZxC7ljM/tP7jTvE1MwmMHE
P8rX5b3yF8DfMdGZdIlrHJ8wXYSzJdTMJvA5ffXVKaObGMYtAFFDlfupud1iO9ML
Hh4exxX+/NU7fXt+ot6BLEFAfDD9+z6uOeq+vK6bxaITubFVGIavhowjAgQIBNt3
O//p9dJQVKan0db9kqyLpLMrrFYd/cmA8DZDxoY/iaVuoKhJ6blbDMQKi2DlsvgF
WGDHUsSBZIYTFq5mc7VO
=eyUN
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

[George Stanchev]

Hi Aurelien,

https://www.dropbox.com/sh/az1r3agxx4w8r7e/AACRGedBG3G5oh4-qE9652WNa?dl=0

It's not a pcap but rather javax.debug logger capture which is similar. I can 
do pcap but since java dumps the stream along with handshake messages 
description, I haven't bothered to capture it. This folder also contains the 
test Java client and an SSPI echo server that emulates the problem and has the 
SSPI calls to demonstrate the issue. "cood capture.txt" is when you run with 
TLSv1-only. "bad capture.txt" is when you run with defaults...If you run the 
java client you need to update

final String targetURL = 
"https://rm9485:443/gsoap/gsoap_ssl.dll?sbminternalservices72;;

to point to the correct machine. Uncommenting 
//System.setProperty("jdk.tls.client.protocols", "TLSv1"); makes the call 
succeed. The SSLServer on the native side will return SEC_E_DECRYPT_FAILURE 
from AcceptSecurityContext() when the TLS connection is upgraded to 2way ssl 
after ClientCertVerify's changing of cipher specs. I spent time in the Java 
handshaker and while I don't understand it enough, I saw the failure right 
after it flushes the  running MAC down the stream onto the server. At this 
point SSPI fails the call with bad_mac_record which is behind the code 
SEC_E_DECRYPT_FAILURE...

George

-Original Message-
From: Aurélien Terrestris [mailto:aterrest...@gmail.com] 
Sent: Tuesday, October 13, 2015 2:23 PM
To: Tomcat Users List
Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

George,

do you have any network capture that we can see ?

2015-10-13 22:10 GMT+02:00 George Stanchev :

> >> It might be doable with OpenSSL s_client or something. Tough to
> replicate Java's behavior with a non-Java tool, though.
>
> I tried hard with the s_client but it can limit the protocols to one 
> or another but it canot mix-and-match (hello 1.2, ok we will do 1.0) 
> like Java
> 8 does. Either TLSv1 or TLSv1.2 but not both. Neither can curl which 
> is also on top of openssl.
>
> Today, I spent 2.5 hours with a lemming from MS getting basically nowhere.
> I really need an engineer, but they give me those clueless support 
> people that is wasting mine and their time. If someone knows how to 
> escalate or a forum where MS developers hang out, I would appreciate 
> it. The support person I got today was clueless, went over a script 
> and any attempt to explain a little more technical details led to 
> total confusion and rebooting the script to beginning. Totally 
> frustrating. At least with Oracle I got to talk with an actual engineer...
>
> George
>
>
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Tuesday, October 13, 2015 2:03 PM
> To: Tomcat Users List
> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, 
> description = bad_record_mac
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> George,
>
> On 10/13/15 12:35 PM, George Stanchev wrote:
> > [1] states: " JDK 7-9 enables SSLv2Hello on the server side only.
> > (Will not send, but will accept SSLv2Hellos)"
>
> Interesting. This absolutely makes sense, though, since SSL should 
> just die. :)
>
> > I've opened support case both MS and already there is a bug filed 
> > with Oracle on this and really, to be absolutely certain if the 
> > issue is in Java or SChannel, one would have to write a non-Java 
> > client that that mimics the handshake messages send from Java with 
> > something like OpenSSL or NSS or whatever and see if the bug replicates.
>
> It might be doable with OpenSSL s_client or something. Tough to 
> replicate Java's behavior with a non-Java tool, though.
>
> > Writing a Java/Java server client could still leave some doubts as 
> > one can argue the code reuse could mask the problem - it works but 
> > the bug on the client side is hidden by the server containing 
> > similar/same bug so the MACs check out...
> >
> > Unfortunately I don't have the time to invest in this more than I 
> > already had. And if MS support engineers can pass it on to someone 
> > from the windows core team may be we can have some movement forward.
>
> Okay. Thanks for your work so far.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJWHWNuAAoJEBzwKT+lPKRYgWAP/A8fUJ5Dzu+O46GNWpdobqq0
> 7ugkb2cQ1VM92Q+22Wtl87GSRPhBS8jwNrBBCJmoyBjRZ/LKVcwtcWLzUIBllXm5
> t8iorXpQxaps1G0AEEf5tAwHXyN75J2vC9qvRvD6dkekHXHwO3RRqvSCqQjEjeVJ
> XsOdjuIhPwX0B0SN8Apdshvxe98sC9QPn73LNdSM9+j8Ob1vCDHDiMFj60K72Su1
> E0UmPYEJdhb5D+PvSM/7CMcAlkJYmCl8VlNFWD320ymjObfIMymfOk+kqKLqVItQ
> +r2e20At1qCyeyg2Gcxb4X1ajIhcxdgP7WJYtg57Pwrp4ZVZ6d7RM+CIqt28SfxT
> EtTamDZ8aPYsCKqMWIYRPyLrWaouEuLJEmzweF8B+NxY0svK8vEOiro/vR4LycOZ
> PG5zxuS/QMJR2oEgkeUz9+NhB8nP/qJxMhc40pKGmvZxC7ljM/tP7jTvE1MwmMHE
> P8rX5b3yF8DfMdGZdIlrHJ8wXYSzJdTMJvA5ffXVKaObGMYtAFFDlfupud1iO9ML
> Hh4exxX+/NU7fXt+ot6BLEFAfDD9+z6uOeq+vK6bxaITubFVGIavhowjAgQIBNt3
> 

Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

[Aurélien Terrestris]

"Another route to try the SSLv2Hello is to hack and recompile the JSSE.
It's on my agenda to learn to do that if possible without rebuilding the
whole JRE since for some obscure reason Oracle compiles JSSE with no debug
info (and it is not included in the srcs distributed with the JRE) on it
which makes debugging and inspecting local vars really hard..."

No, it's not needed. I use jtouch.sourceforge.net and it's working well for
trying SSLv2 hello's. From the network captures, I see that it's working.
Not making advertisement for my software here, but,.. ;)







2015-10-13 23:20 GMT+02:00 George Stanchev :

> Just as a side note, https.protocols is read by HttpsUrlConnection which
> feeds it down through setEnabledProtocols() on the SSL socket. "
> jdk.tls.client.protocols" is read directly by JSSE and does the same
> thing...
>
> Another route to try the SSLv2Hello is to hack and recompile the JSSE.
> It's on my agenda to learn to do that if possible without rebuilding the
> whole JRE since for some obscure reason Oracle compiles JSSE with no debug
> info (and it is not included in the srcs distributed with the JRE) on it
> which makes debugging and inspecting local vars really hard...
>
> George
>
> -Original Message-
> From: Aurélien Terrestris [mailto:aterrest...@gmail.com]
> Sent: Tuesday, October 13, 2015 3:13 PM
> To: Tomcat Users List
> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal,
> description = bad_record_mac
>
> Maybe writing too fast..
>
> "How do you force Java 8 to use SSLv2Hello?"
>
> As suggested before, by writing your own client OR by trying this hack.
> From the JSSE Ref Guide 5, we know how to the customize the protocol (
> https://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#InstallationAndCustomization
> ) by setting a system property (https.protocol). Although they are no more
> talking about this in the Ref Guide 8 (
> https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
> ) I would give it a try as I know that the documentation is poorly written.
> I suggested 10 years ago a change in the API doc about the enabled
> protocols, and they didn't change anything although they said they would.
>
>
>
> "[1] states: " JDK 7-9 enables SSLv2Hello on the server side only.  (Will
> not send, but will accept SSLv2Hellos)""
>
> I believe they mean "by default" as for the client side. Poorly written,
> probably.
>
>
>
> 2015-10-13 22:55 GMT+02:00 Aurélien Terrestris :
>
> > "How do you force Java 8 to use SSLv2Hello?"
> >
> > You can do this when writing your own Java client : calling the
> > SSLSocketFactory to create an SSLSocket and configure with
> > setEnabledProtocols (
> > https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocket.html
> > #setEnabledProtocols-java.lang.String:A-
> > )
> >
> > If you have some IIS server on internet which reproduces the problem,
> > I'll try with JTouch ( jtouch.sourceforge.net ) or write a small client.
> >
> >
> >
> >
> > 2015-10-13 22:22 GMT+02:00 Aurélien Terrestris :
> >
> >> George,
> >>
> >> do you have any network capture that we can see ?
> >>
> >> 2015-10-13 22:10 GMT+02:00 George Stanchev :
> >>
> >>> >> It might be doable with OpenSSL s_client or something. Tough to
> >>> replicate Java's behavior with a non-Java tool, though.
> >>>
> >>> I tried hard with the s_client but it can limit the protocols to one
> >>> or another but it canot mix-and-match (hello 1.2, ok we will do 1.0)
> >>> like Java
> >>> 8 does. Either TLSv1 or TLSv1.2 but not both. Neither can curl which
> >>> is also on top of openssl.
> >>>
> >>> Today, I spent 2.5 hours with a lemming from MS getting basically
> >>> nowhere. I really need an engineer, but they give me those clueless
> >>> support people that is wasting mine and their time. If someone knows
> >>> how to escalate or a forum where MS developers hang out, I would
> appreciate it.
> >>> The support person I got today was clueless, went over a script and
> >>> any attempt to explain a little more technical details led to total
> >>> confusion and rebooting the script to beginning. Totally
> >>> frustrating. At least with Oracle I got to talk with an actual
> engineer...
> >>>
> >>> George
> >>>
> >>>
> >>> -Original Message-
> >>> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> >>> Sent: Tuesday, October 13, 2015 2:03 PM
> >>> To: Tomcat Users List
> >>> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal,
> >>> description = bad_record_mac
> >>>
> >>> -BEGIN PGP SIGNED MESSAGE-
> >>> Hash: SHA256
> >>>
> >>> George,
> >>>
> >>> On 10/13/15 12:35 PM, George Stanchev wrote:
> >>> > [1] states: " JDK 7-9 enables SSLv2Hello on the server side only.
> >>> > (Will not send, but will accept SSLv2Hellos)"
> >>>
> >>> Interesting. This absolutely makes sense, though, since SSL 

Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

George and Aurélien,

On 10/13/15 5:06 PM, George Stanchev wrote:
> Try the dropbox location in my prev messages. It contains a sample 
> echo server you can use to test. It is a Visual Studio 2013
> project. In case you don’t have that, I've uploaded x64 executables
> under SSLServer_executbale.zip. It is pretty much self contained,
> it has the redist DLLs, the server cert, all...
> 
> It eliminates the need of IIS as it does the same thing - accept 
> connection, read payload, upgrade to 2 way ssl...
> 
> It generates output like this [1]
> 
> The line " Decrypt error from SCHANNEL, Client ID: 
> a1cefeb8-bad3-4903-8dbe-fdea347f666e" is emitted when bad record
> mac is caught on the server side...

On 10/13/15 4:55 PM, Aurélien Terrestris wrote:
> "How do you force Java 8 to use SSLv2Hello?"
> 
> You can do this when writing your own Java client : calling the 
> SSLSocketFactory to create an SSLSocket and configure with 
> setEnabledProtocols (
> 
https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocket.html#s
etEnabledProtocols-java.lang.String:A-
> )
> 
> If you have some IIS server on internet which reproduces the
> problem, I'll try with JTouch ( jtouch.sourceforge.net ) or write a
> small client.

I've got a client already written. I'll post the latest code somewhere.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWHXLNAAoJEBzwKT+lPKRYCp4P+wZX2tiJ41FlRIYSK1sf7kAl
0yBJiFGDChNa8+zYvs5WYGcOFCQmBHXHepJTi7Zff3G0NrRcgEAS/Yo9yUjSFPBJ
R0kRoIUAwdeU882lhCkRulC8SyJZv6jq13NqUjYO9J4GACf58rweFfZcF5o/5RL8
rZ7ZSgXNj/VyXIilOKuZ3Ak6262X7qLnlhnSnXImSfZJND2PKf0l05cL4jrObtaA
mqWv/zuGdDfRKJgBWMo9oHxjGfe+c9NDIm18uFUf23hMbuX9bJImQ+LLAXgibUTk
eRuqr1igjAqqqnVPowDOLX/CKH7ikQ+ZygPvzFvztjeEXC4IhBj8hC/LjPG7tkfl
XNZVD0K1ryni0f/qWvyTL5MHGiJX1+zS6VFm3cYTif+FREvg1P4eGxAFIFwAHQgm
2Yz3N1+r8qJHnVSjQoDlbjPcB9ba2xDg+gMyryDTx0Zxc83qzVOfOdcMuHWgwqTD
5b9KlzdqLzhh7mXj9L5/+L2EomsehWayzM4PLv31QVrv1UzR3vA/6L64Pwe0n512
9VdDMgk3qX54RHetxpE63JYl9EtmWVaE1GxOb/ar1kPi4h08TTTvs2Vtxk3i+F8Y
sv1KLziEW1MsQg1l8Nvn++5GoLhTNJapra3FYBkpitK3AMObip3G7hOPIqdu/C8P
HtBxh5fmOEqYmDC2UB5c
=3OPW
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

[George Stanchev]

Ok, may be you are ahead of me on this one, but setEnabledProtocols(), to my 
understanding does the same as the system property "jdk.tls.client.protocols". 
It gives the JSSE a pool of protocols to choose from but it will be up to JSSE 
to select the ClientHello version. I might have missed something but I spent 
quite a bit of time in the Handshaker and related classes in the JDK and 
couldn't see anything that can change that...

George

-Original Message-
From: Aurélien Terrestris [mailto:aterrest...@gmail.com] 
Sent: Tuesday, October 13, 2015 2:55 PM
To: Tomcat Users List
Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

"How do you force Java 8 to use SSLv2Hello?"

You can do this when writing your own Java client : calling the 
SSLSocketFactory to create an SSLSocket and configure with setEnabledProtocols (
https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocket.html#setEnabledProtocols-java.lang.String:A-
)

If you have some IIS server on internet which reproduces the problem, I'll try 
with JTouch ( jtouch.sourceforge.net ) or write a small client.




2015-10-13 22:22 GMT+02:00 Aurélien Terrestris :

> George,
>
> do you have any network capture that we can see ?
>
> 2015-10-13 22:10 GMT+02:00 George Stanchev :
>
>> >> It might be doable with OpenSSL s_client or something. Tough to
>> replicate Java's behavior with a non-Java tool, though.
>>
>> I tried hard with the s_client but it can limit the protocols to one 
>> or another but it canot mix-and-match (hello 1.2, ok we will do 1.0) 
>> like Java
>> 8 does. Either TLSv1 or TLSv1.2 but not both. Neither can curl which 
>> is also on top of openssl.
>>
>> Today, I spent 2.5 hours with a lemming from MS getting basically 
>> nowhere. I really need an engineer, but they give me those clueless 
>> support people that is wasting mine and their time. If someone knows 
>> how to escalate or a forum where MS developers hang out, I would appreciate 
>> it.
>> The support person I got today was clueless, went over a script and 
>> any attempt to explain a little more technical details led to total 
>> confusion and rebooting the script to beginning. Totally frustrating. 
>> At least with Oracle I got to talk with an actual engineer...
>>
>> George
>>
>>
>> -Original Message-
>> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>> Sent: Tuesday, October 13, 2015 2:03 PM
>> To: Tomcat Users List
>> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, 
>> description = bad_record_mac
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> George,
>>
>> On 10/13/15 12:35 PM, George Stanchev wrote:
>> > [1] states: " JDK 7-9 enables SSLv2Hello on the server side only.
>> > (Will not send, but will accept SSLv2Hellos)"
>>
>> Interesting. This absolutely makes sense, though, since SSL should 
>> just die. :)
>>
>> > I've opened support case both MS and already there is a bug filed 
>> > with Oracle on this and really, to be absolutely certain if the 
>> > issue is in Java or SChannel, one would have to write a non-Java 
>> > client that that mimics the handshake messages send from Java with 
>> > something like OpenSSL or NSS or whatever and see if the bug replicates.
>>
>> It might be doable with OpenSSL s_client or something. Tough to 
>> replicate Java's behavior with a non-Java tool, though.
>>
>> > Writing a Java/Java server client could still leave some doubts as 
>> > one can argue the code reuse could mask the problem - it works but 
>> > the bug on the client side is hidden by the server containing 
>> > similar/same bug so the MACs check out...
>> >
>> > Unfortunately I don't have the time to invest in this more than I 
>> > already had. And if MS support engineers can pass it on to someone 
>> > from the windows core team may be we can have some movement forward.
>>
>> Okay. Thanks for your work so far.
>>
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Comment: GPGTools - http://gpgtools.org
>>
>> iQIcBAEBCAAGBQJWHWNuAAoJEBzwKT+lPKRYgWAP/A8fUJ5Dzu+O46GNWpdobqq0
>> 7ugkb2cQ1VM92Q+22Wtl87GSRPhBS8jwNrBBCJmoyBjRZ/LKVcwtcWLzUIBllXm5
>> t8iorXpQxaps1G0AEEf5tAwHXyN75J2vC9qvRvD6dkekHXHwO3RRqvSCqQjEjeVJ
>> XsOdjuIhPwX0B0SN8Apdshvxe98sC9QPn73LNdSM9+j8Ob1vCDHDiMFj60K72Su1
>> E0UmPYEJdhb5D+PvSM/7CMcAlkJYmCl8VlNFWD320ymjObfIMymfOk+kqKLqVItQ
>> +r2e20At1qCyeyg2Gcxb4X1ajIhcxdgP7WJYtg57Pwrp4ZVZ6d7RM+CIqt28SfxT
>> EtTamDZ8aPYsCKqMWIYRPyLrWaouEuLJEmzweF8B+NxY0svK8vEOiro/vR4LycOZ
>> PG5zxuS/QMJR2oEgkeUz9+NhB8nP/qJxMhc40pKGmvZxC7ljM/tP7jTvE1MwmMHE
>> P8rX5b3yF8DfMdGZdIlrHJ8wXYSzJdTMJvA5ffXVKaObGMYtAFFDlfupud1iO9ML
>> Hh4exxX+/NU7fXt+ot6BLEFAfDD9+z6uOeq+vK6bxaITubFVGIavhowjAgQIBNt3
>> O//p9dJQVKan0db9kqyLpLMrrFYd/cmA8DZDxoY/iaVuoKhJ6blbDMQKi2DlsvgF
>> WGDHUsSBZIYTFq5mc7VO
>> =eyUN
>> -END PGP SIGNATURE-
>>
>> -
>> To unsubscribe, e-mail: 

Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

[Aurélien Terrestris]

"How do you force Java 8 to use SSLv2Hello?"

You can do this when writing your own Java client : calling the
SSLSocketFactory to create an SSLSocket and configure with
setEnabledProtocols (
https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocket.html#setEnabledProtocols-java.lang.String:A-
)

If you have some IIS server on internet which reproduces the problem, I'll
try with JTouch ( jtouch.sourceforge.net ) or write a small client.




2015-10-13 22:22 GMT+02:00 Aurélien Terrestris :

> George,
>
> do you have any network capture that we can see ?
>
> 2015-10-13 22:10 GMT+02:00 George Stanchev :
>
>> >> It might be doable with OpenSSL s_client or something. Tough to
>> replicate Java's behavior with a non-Java tool, though.
>>
>> I tried hard with the s_client but it can limit the protocols to one or
>> another but it canot mix-and-match (hello 1.2, ok we will do 1.0) like Java
>> 8 does. Either TLSv1 or TLSv1.2 but not both. Neither can curl which is
>> also on top of openssl.
>>
>> Today, I spent 2.5 hours with a lemming from MS getting basically
>> nowhere. I really need an engineer, but they give me those clueless support
>> people that is wasting mine and their time. If someone knows how to
>> escalate or a forum where MS developers hang out, I would appreciate it.
>> The support person I got today was clueless, went over a script and any
>> attempt to explain a little more technical details led to total confusion
>> and rebooting the script to beginning. Totally frustrating. At least with
>> Oracle I got to talk with an actual engineer...
>>
>> George
>>
>>
>> -Original Message-
>> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>> Sent: Tuesday, October 13, 2015 2:03 PM
>> To: Tomcat Users List
>> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal,
>> description = bad_record_mac
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> George,
>>
>> On 10/13/15 12:35 PM, George Stanchev wrote:
>> > [1] states: " JDK 7-9 enables SSLv2Hello on the server side only.
>> > (Will not send, but will accept SSLv2Hellos)"
>>
>> Interesting. This absolutely makes sense, though, since SSL should just
>> die. :)
>>
>> > I've opened support case both MS and already there is a bug filed with
>> > Oracle on this and really, to be absolutely certain if the issue is in
>> > Java or SChannel, one would have to write a non-Java client that that
>> > mimics the handshake messages send from Java with something like
>> > OpenSSL or NSS or whatever and see if the bug replicates.
>>
>> It might be doable with OpenSSL s_client or something. Tough to replicate
>> Java's behavior with a non-Java tool, though.
>>
>> > Writing a Java/Java server client could still leave some doubts as one
>> > can argue the code reuse could mask the problem - it works but the bug
>> > on the client side is hidden by the server containing similar/same bug
>> > so the MACs check out...
>> >
>> > Unfortunately I don't have the time to invest in this more than I
>> > already had. And if MS support engineers can pass it on to someone
>> > from the windows core team may be we can have some movement forward.
>>
>> Okay. Thanks for your work so far.
>>
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Comment: GPGTools - http://gpgtools.org
>>
>> iQIcBAEBCAAGBQJWHWNuAAoJEBzwKT+lPKRYgWAP/A8fUJ5Dzu+O46GNWpdobqq0
>> 7ugkb2cQ1VM92Q+22Wtl87GSRPhBS8jwNrBBCJmoyBjRZ/LKVcwtcWLzUIBllXm5
>> t8iorXpQxaps1G0AEEf5tAwHXyN75J2vC9qvRvD6dkekHXHwO3RRqvSCqQjEjeVJ
>> XsOdjuIhPwX0B0SN8Apdshvxe98sC9QPn73LNdSM9+j8Ob1vCDHDiMFj60K72Su1
>> E0UmPYEJdhb5D+PvSM/7CMcAlkJYmCl8VlNFWD320ymjObfIMymfOk+kqKLqVItQ
>> +r2e20At1qCyeyg2Gcxb4X1ajIhcxdgP7WJYtg57Pwrp4ZVZ6d7RM+CIqt28SfxT
>> EtTamDZ8aPYsCKqMWIYRPyLrWaouEuLJEmzweF8B+NxY0svK8vEOiro/vR4LycOZ
>> PG5zxuS/QMJR2oEgkeUz9+NhB8nP/qJxMhc40pKGmvZxC7ljM/tP7jTvE1MwmMHE
>> P8rX5b3yF8DfMdGZdIlrHJ8wXYSzJdTMJvA5ffXVKaObGMYtAFFDlfupud1iO9ML
>> Hh4exxX+/NU7fXt+ot6BLEFAfDD9+z6uOeq+vK6bxaITubFVGIavhowjAgQIBNt3
>> O//p9dJQVKan0db9kqyLpLMrrFYd/cmA8DZDxoY/iaVuoKhJ6blbDMQKi2DlsvgF
>> WGDHUsSBZIYTFq5mc7VO
>> =eyUN
>> -END PGP SIGNATURE-
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

[George Stanchev]

Aurlien,

Try the dropbox location in my prev messages. It contains a sample echo server 
you can use to test. It is a Visual Studio 2013 project. In case you don’t have 
that, I've uploaded x64 executables under SSLServer_executbale.zip. It is 
pretty much self contained, it has the redist DLLs, the server cert, all...

It eliminates the need of IIS as it does the same thing - accept connection, 
read payload, upgrade to 2 way ssl...

It generates output like this [1]

The line " Decrypt error from SCHANNEL, Client ID: 
a1cefeb8-bad3-4903-8dbe-fdea347f666e" is emitted when bad record mac is caught 
on the server side...

George



[1]


Read: 1093 bytes from 192.168.2.164:41525
Read: 165 bytes from 192.168.2.164:41525
Read: 90 bytes from 192.168.2.164:41525
Decrypt error from SCHANNEL, Client ID: a1cefeb8-bad3-4903-8dbe-fdea347f666e
Removing Dead Connection, Client ID: a1cefeb8-bad3-4903-8dbe-fdea347f666e
Active Connections: 0
New Connection from 192.168.2.164:41526 with Client ID: a94811d3-0872-4b63-a429-
97f980fdc42d
Read: 89 bytes from 192.168.2.164:41526
Sent: 145 bytes to 192.168.2.164:41526
Read: 6 bytes from 192.168.2.164:41526
Read: 53 bytes from 192.168.2.164:41526
Handshake Success, Client ID: a94811d3-0872-4b63-a429-97f980fdc42d
Read: 213 bytes from 192.168.2.164:41526
Message Client ID: SSL renegotiation: request client cert
Handshake Success, Client ID: a94811d3-0872-4b63-a429-97f980fdc42d
Sent: 37 bytes to 192.168.2.164:41526
Read: 133 bytes from 192.168.2.164:41526
Sent: 805 bytes to 192.168.2.164:41526
Read: 1093 bytes from 192.168.2.164:41526
Read: 165 bytes from 192.168.2.164:41526
Read: 90 bytes from 192.168.2.164:41526
Sent: 90 bytes to 192.168.2.164:41526
Handshake Success, Client ID: a94811d3-0872-4b63-a429-97f980fdc42d

-Original Message-
From: Aurélien Terrestris [mailto:aterrest...@gmail.com] 
Sent: Tuesday, October 13, 2015 2:55 PM
To: Tomcat Users List
Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

"How do you force Java 8 to use SSLv2Hello?"

You can do this when writing your own Java client : calling the 
SSLSocketFactory to create an SSLSocket and configure with setEnabledProtocols (
https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocket.html#setEnabledProtocols-java.lang.String:A-
)

If you have some IIS server on internet which reproduces the problem, I'll try 
with JTouch ( jtouch.sourceforge.net ) or write a small client.




2015-10-13 22:22 GMT+02:00 Aurélien Terrestris :

> George,
>
> do you have any network capture that we can see ?
>
> 2015-10-13 22:10 GMT+02:00 George Stanchev :
>
>> >> It might be doable with OpenSSL s_client or something. Tough to
>> replicate Java's behavior with a non-Java tool, though.
>>
>> I tried hard with the s_client but it can limit the protocols to one 
>> or another but it canot mix-and-match (hello 1.2, ok we will do 1.0) 
>> like Java
>> 8 does. Either TLSv1 or TLSv1.2 but not both. Neither can curl which 
>> is also on top of openssl.
>>
>> Today, I spent 2.5 hours with a lemming from MS getting basically 
>> nowhere. I really need an engineer, but they give me those clueless 
>> support people that is wasting mine and their time. If someone knows 
>> how to escalate or a forum where MS developers hang out, I would appreciate 
>> it.
>> The support person I got today was clueless, went over a script and 
>> any attempt to explain a little more technical details led to total 
>> confusion and rebooting the script to beginning. Totally frustrating. 
>> At least with Oracle I got to talk with an actual engineer...
>>
>> George
>>
>>
>> -Original Message-
>> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>> Sent: Tuesday, October 13, 2015 2:03 PM
>> To: Tomcat Users List
>> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, 
>> description = bad_record_mac
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> George,
>>
>> On 10/13/15 12:35 PM, George Stanchev wrote:
>> > [1] states: " JDK 7-9 enables SSLv2Hello on the server side only.
>> > (Will not send, but will accept SSLv2Hellos)"
>>
>> Interesting. This absolutely makes sense, though, since SSL should 
>> just die. :)
>>
>> > I've opened support case both MS and already there is a bug filed 
>> > with Oracle on this and really, to be absolutely certain if the 
>> > issue is in Java or SChannel, one would have to write a non-Java 
>> > client that that mimics the handshake messages send from Java with 
>> > something like OpenSSL or NSS or whatever and see if the bug replicates.
>>
>> It might be doable with OpenSSL s_client or something. Tough to 
>> replicate Java's behavior with a non-Java tool, though.
>>
>> > Writing a Java/Java server client could still leave some doubts as 
>> > one can argue the code reuse could mask the problem - it works but 
>> > the bug on the client side is hidden by the server containing 

Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

[Aurélien Terrestris]

Maybe writing too fast..

"How do you force Java 8 to use SSLv2Hello?"

As suggested before, by writing your own client OR by trying this hack.
>From the JSSE Ref Guide 5, we know how to the customize the protocol (
https://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#InstallationAndCustomization
) by setting a system property (https.protocol). Although they are no more
talking about this in the Ref Guide 8 (
https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
) I would give it a try as I know that the documentation is poorly written.
I suggested 10 years ago a change in the API doc about the enabled
protocols, and they didn't change anything although they said they would.



"[1] states: " JDK 7-9 enables SSLv2Hello on the server side only.  (Will
not send, but will accept SSLv2Hellos)""

I believe they mean "by default" as for the client side. Poorly written,
probably.



2015-10-13 22:55 GMT+02:00 Aurélien Terrestris :

> "How do you force Java 8 to use SSLv2Hello?"
>
> You can do this when writing your own Java client : calling the
> SSLSocketFactory to create an SSLSocket and configure with
> setEnabledProtocols (
> https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocket.html#setEnabledProtocols-java.lang.String:A-
> )
>
> If you have some IIS server on internet which reproduces the problem, I'll
> try with JTouch ( jtouch.sourceforge.net ) or write a small client.
>
>
>
>
> 2015-10-13 22:22 GMT+02:00 Aurélien Terrestris :
>
>> George,
>>
>> do you have any network capture that we can see ?
>>
>> 2015-10-13 22:10 GMT+02:00 George Stanchev :
>>
>>> >> It might be doable with OpenSSL s_client or something. Tough to
>>> replicate Java's behavior with a non-Java tool, though.
>>>
>>> I tried hard with the s_client but it can limit the protocols to one or
>>> another but it canot mix-and-match (hello 1.2, ok we will do 1.0) like Java
>>> 8 does. Either TLSv1 or TLSv1.2 but not both. Neither can curl which is
>>> also on top of openssl.
>>>
>>> Today, I spent 2.5 hours with a lemming from MS getting basically
>>> nowhere. I really need an engineer, but they give me those clueless support
>>> people that is wasting mine and their time. If someone knows how to
>>> escalate or a forum where MS developers hang out, I would appreciate it.
>>> The support person I got today was clueless, went over a script and any
>>> attempt to explain a little more technical details led to total confusion
>>> and rebooting the script to beginning. Totally frustrating. At least with
>>> Oracle I got to talk with an actual engineer...
>>>
>>> George
>>>
>>>
>>> -Original Message-
>>> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>>> Sent: Tuesday, October 13, 2015 2:03 PM
>>> To: Tomcat Users List
>>> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal,
>>> description = bad_record_mac
>>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>>
>>> George,
>>>
>>> On 10/13/15 12:35 PM, George Stanchev wrote:
>>> > [1] states: " JDK 7-9 enables SSLv2Hello on the server side only.
>>> > (Will not send, but will accept SSLv2Hellos)"
>>>
>>> Interesting. This absolutely makes sense, though, since SSL should just
>>> die. :)
>>>
>>> > I've opened support case both MS and already there is a bug filed with
>>> > Oracle on this and really, to be absolutely certain if the issue is in
>>> > Java or SChannel, one would have to write a non-Java client that that
>>> > mimics the handshake messages send from Java with something like
>>> > OpenSSL or NSS or whatever and see if the bug replicates.
>>>
>>> It might be doable with OpenSSL s_client or something. Tough to
>>> replicate Java's behavior with a non-Java tool, though.
>>>
>>> > Writing a Java/Java server client could still leave some doubts as one
>>> > can argue the code reuse could mask the problem - it works but the bug
>>> > on the client side is hidden by the server containing similar/same bug
>>> > so the MACs check out...
>>> >
>>> > Unfortunately I don't have the time to invest in this more than I
>>> > already had. And if MS support engineers can pass it on to someone
>>> > from the windows core team may be we can have some movement forward.
>>>
>>> Okay. Thanks for your work so far.
>>>
>>> - -chris
>>> -BEGIN PGP SIGNATURE-
>>> Comment: GPGTools - http://gpgtools.org
>>>
>>> iQIcBAEBCAAGBQJWHWNuAAoJEBzwKT+lPKRYgWAP/A8fUJ5Dzu+O46GNWpdobqq0
>>> 7ugkb2cQ1VM92Q+22Wtl87GSRPhBS8jwNrBBCJmoyBjRZ/LKVcwtcWLzUIBllXm5
>>> t8iorXpQxaps1G0AEEf5tAwHXyN75J2vC9qvRvD6dkekHXHwO3RRqvSCqQjEjeVJ
>>> XsOdjuIhPwX0B0SN8Apdshvxe98sC9QPn73LNdSM9+j8Ob1vCDHDiMFj60K72Su1
>>> E0UmPYEJdhb5D+PvSM/7CMcAlkJYmCl8VlNFWD320ymjObfIMymfOk+kqKLqVItQ
>>> +r2e20At1qCyeyg2Gcxb4X1ajIhcxdgP7WJYtg57Pwrp4ZVZ6d7RM+CIqt28SfxT
>>> EtTamDZ8aPYsCKqMWIYRPyLrWaouEuLJEmzweF8B+NxY0svK8vEOiro/vR4LycOZ
>>> 

Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

On 10/13/15 5:08 PM, Christopher Schultz wrote:
> George and Aurélien,
> 
> On 10/13/15 5:06 PM, George Stanchev wrote:
>> Try the dropbox location in my prev messages. It contains a
>> sample echo server you can use to test. It is a Visual Studio
>> 2013 project. In case you don’t have that, I've uploaded x64
>> executables under SSLServer_executbale.zip. It is pretty much
>> self contained, it has the redist DLLs, the server cert, all...
> 
>> It eliminates the need of IIS as it does the same thing - accept
>>  connection, read payload, upgrade to 2 way ssl...
> 
>> It generates output like this [1]
> 
>> The line " Decrypt error from SCHANNEL, Client ID: 
>> a1cefeb8-bad3-4903-8dbe-fdea347f666e" is emitted when bad record 
>> mac is caught on the server side...
> 
> On 10/13/15 4:55 PM, Aurélien Terrestris wrote:
>> "How do you force Java 8 to use SSLv2Hello?"
> 
>> You can do this when writing your own Java client : calling the 
>> SSLSocketFactory to create an SSLSocket and configure with 
>> setEnabledProtocols (
> 
> https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocket.html
#s
>
> 
etEnabledProtocols-java.lang.String:A-
>> )
> 
>> If you have some IIS server on internet which reproduces the 
>> problem, I'll try with JTouch ( jtouch.sourceforge.net ) or write
>> a small client.
> 
> I've got a client already written. I'll post the latest code
> somewhere.

https://wiki.apache.org/tomcat/tools/SSLTest.java
and
https://wiki.apache.org/tomcat/tools/SSLUtils.java

This tool only performs the SSL handshake, so it doesn't do anything
at the HTTP level. It doesn't do client certificates; I'd be happy to
see someone add that capability and update the code on the Wiki.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWHXaUAAoJEBzwKT+lPKRYTgcQAKdzEBtjLyCbkBBlJJObUxm0
dxAhLIFfBkcmo0IquMUJBnCHJ9hfuuhnXDvzLhvvAhfoiG8CkGfcjw79LwcL49iO
+eAuz1bycFvfSoVW+ZEPIXl13n4v+t2hBYfGJJgcYefOBJBfIGLHTazmi53F9vfn
zrnno6wRZkZ+JrFrzSlfMMvWnOE7Uv5ZDKw/8tv85ZTPuIIdIud8Uy0Z5J3HHgYx
t5WBL3JaqLcUihIUUuibSfmw27iyfKPv6OusoVPKc9pKb+uWoLftyE4d4btVTFEV
qDAdmW3XaA/1GHZ3n5szHND+EkdKkiiic7mHRgsN+4F/AH3KVoWs9+Qw9vOhO+da
XgeehuKB1nfnNrhI1n4eEoYC+P162GxVqNKIsKFat38BGEZlCRaAt8UtsfhE0AvO
2gaF1k1vyYcCoXhNYF9WQLatnx1MXeAZMYw3oAZPOusDoqtGElCJfYc1K8iJayEl
bBzYojkzLjFqPfJJ8tvCqBwkngNCw6MgyqVbYSMxDREQtZBa2xYGLHv9bWL0Kp+6
Q5Y3u4uks7OCGH+Usfvq82ZGnp6mnneA2jgAd0KWSJDjKcaNUWQVOirPVTFnpNmh
+dUZUM/gR1CIQHoiu8i8NH9qn2jtBtDvnYRWswzJlt9tOpaxPQWwdBL86gj4cWHp
aGwTUveYwOgLokoEUXHO
=Iha7
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

[George Stanchev]

Just as a side note, https.protocols is read by HttpsUrlConnection which feeds 
it down through setEnabledProtocols() on the SSL socket. " 
jdk.tls.client.protocols" is read directly by JSSE and does the same thing...

Another route to try the SSLv2Hello is to hack and recompile the JSSE. It's on 
my agenda to learn to do that if possible without rebuilding the whole JRE 
since for some obscure reason Oracle compiles JSSE with no debug info (and it 
is not included in the srcs distributed with the JRE) on it which makes 
debugging and inspecting local vars really hard...

George

-Original Message-
From: Aurélien Terrestris [mailto:aterrest...@gmail.com] 
Sent: Tuesday, October 13, 2015 3:13 PM
To: Tomcat Users List
Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

Maybe writing too fast..

"How do you force Java 8 to use SSLv2Hello?"

As suggested before, by writing your own client OR by trying this hack.
From the JSSE Ref Guide 5, we know how to the customize the protocol ( 
https://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#InstallationAndCustomization
) by setting a system property (https.protocol). Although they are no more 
talking about this in the Ref Guide 8 ( 
https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider
) I would give it a try as I know that the documentation is poorly written.
I suggested 10 years ago a change in the API doc about the enabled protocols, 
and they didn't change anything although they said they would.



"[1] states: " JDK 7-9 enables SSLv2Hello on the server side only.  (Will not 
send, but will accept SSLv2Hellos)""

I believe they mean "by default" as for the client side. Poorly written, 
probably.



2015-10-13 22:55 GMT+02:00 Aurélien Terrestris :

> "How do you force Java 8 to use SSLv2Hello?"
>
> You can do this when writing your own Java client : calling the 
> SSLSocketFactory to create an SSLSocket and configure with 
> setEnabledProtocols (
> https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocket.html
> #setEnabledProtocols-java.lang.String:A-
> )
>
> If you have some IIS server on internet which reproduces the problem, 
> I'll try with JTouch ( jtouch.sourceforge.net ) or write a small client.
>
>
>
>
> 2015-10-13 22:22 GMT+02:00 Aurélien Terrestris :
>
>> George,
>>
>> do you have any network capture that we can see ?
>>
>> 2015-10-13 22:10 GMT+02:00 George Stanchev :
>>
>>> >> It might be doable with OpenSSL s_client or something. Tough to
>>> replicate Java's behavior with a non-Java tool, though.
>>>
>>> I tried hard with the s_client but it can limit the protocols to one 
>>> or another but it canot mix-and-match (hello 1.2, ok we will do 1.0) 
>>> like Java
>>> 8 does. Either TLSv1 or TLSv1.2 but not both. Neither can curl which 
>>> is also on top of openssl.
>>>
>>> Today, I spent 2.5 hours with a lemming from MS getting basically 
>>> nowhere. I really need an engineer, but they give me those clueless 
>>> support people that is wasting mine and their time. If someone knows 
>>> how to escalate or a forum where MS developers hang out, I would appreciate 
>>> it.
>>> The support person I got today was clueless, went over a script and 
>>> any attempt to explain a little more technical details led to total 
>>> confusion and rebooting the script to beginning. Totally 
>>> frustrating. At least with Oracle I got to talk with an actual engineer...
>>>
>>> George
>>>
>>>
>>> -Original Message-
>>> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>>> Sent: Tuesday, October 13, 2015 2:03 PM
>>> To: Tomcat Users List
>>> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, 
>>> description = bad_record_mac
>>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>>
>>> George,
>>>
>>> On 10/13/15 12:35 PM, George Stanchev wrote:
>>> > [1] states: " JDK 7-9 enables SSLv2Hello on the server side only.
>>> > (Will not send, but will accept SSLv2Hellos)"
>>>
>>> Interesting. This absolutely makes sense, though, since SSL should 
>>> just die. :)
>>>
>>> > I've opened support case both MS and already there is a bug filed 
>>> > with Oracle on this and really, to be absolutely certain if the 
>>> > issue is in Java or SChannel, one would have to write a non-Java 
>>> > client that that mimics the handshake messages send from Java with 
>>> > something like OpenSSL or NSS or whatever and see if the bug replicates.
>>>
>>> It might be doable with OpenSSL s_client or something. Tough to 
>>> replicate Java's behavior with a non-Java tool, though.
>>>
>>> > Writing a Java/Java server client could still leave some doubts as 
>>> > one can argue the code reuse could mask the problem - it works but 
>>> > the bug on the client side is hidden by the server containing 
>>> > similar/same bug so the MACs check out...
>>> >
>>> > 

Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

[Aurélien Terrestris]

"Ok, may be you are ahead of me on this one, but setEnabledProtocols(), to
my understanding does the same as the system property
"jdk.tls.client.protocols". It gives the JSSE a pool of protocols to choose
from but it will be up to JSSE to select the ClientHello version. I might
have missed something but I spent quite a bit of time in the Handshaker and
related classes in the JDK and couldn't see anything that can change
that..."

Sorry, but I believe that no. To understand, you need to look to the old
Ref Guide (
https://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#InstallationAndCustomization
) which in "Annex A" says that you context.getInstance() takes one argument
called "protocol" while sslsocket.setEnabledProtocols() takes a list of
protocols including the SSLv2Hello.
If you are about to write a TLS client using a SSLv2Hello, you will call
getInstance("TLS") and setEnabledProtocols("SSLv2").

I hope things are more understandable :)




2015-10-13 23:12 GMT+02:00 George Stanchev :

> Ok, may be you are ahead of me on this one, but setEnabledProtocols(), to
> my understanding does the same as the system property
> "jdk.tls.client.protocols". It gives the JSSE a pool of protocols to choose
> from but it will be up to JSSE to select the ClientHello version. I might
> have missed something but I spent quite a bit of time in the Handshaker and
> related classes in the JDK and couldn't see anything that can change that...
>
> George
>
> -Original Message-
> From: Aurélien Terrestris [mailto:aterrest...@gmail.com]
> Sent: Tuesday, October 13, 2015 2:55 PM
> To: Tomcat Users List
> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal,
> description = bad_record_mac
>
> "How do you force Java 8 to use SSLv2Hello?"
>
> You can do this when writing your own Java client : calling the
> SSLSocketFactory to create an SSLSocket and configure with
> setEnabledProtocols (
>
> https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocket.html#setEnabledProtocols-java.lang.String:A-
> )
>
> If you have some IIS server on internet which reproduces the problem, I'll
> try with JTouch ( jtouch.sourceforge.net ) or write a small client.
>
>
>
>
> 2015-10-13 22:22 GMT+02:00 Aurélien Terrestris :
>
> > George,
> >
> > do you have any network capture that we can see ?
> >
> > 2015-10-13 22:10 GMT+02:00 George Stanchev :
> >
> >> >> It might be doable with OpenSSL s_client or something. Tough to
> >> replicate Java's behavior with a non-Java tool, though.
> >>
> >> I tried hard with the s_client but it can limit the protocols to one
> >> or another but it canot mix-and-match (hello 1.2, ok we will do 1.0)
> >> like Java
> >> 8 does. Either TLSv1 or TLSv1.2 but not both. Neither can curl which
> >> is also on top of openssl.
> >>
> >> Today, I spent 2.5 hours with a lemming from MS getting basically
> >> nowhere. I really need an engineer, but they give me those clueless
> >> support people that is wasting mine and their time. If someone knows
> >> how to escalate or a forum where MS developers hang out, I would
> appreciate it.
> >> The support person I got today was clueless, went over a script and
> >> any attempt to explain a little more technical details led to total
> >> confusion and rebooting the script to beginning. Totally frustrating.
> >> At least with Oracle I got to talk with an actual engineer...
> >>
> >> George
> >>
> >>
> >> -Original Message-
> >> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> >> Sent: Tuesday, October 13, 2015 2:03 PM
> >> To: Tomcat Users List
> >> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal,
> >> description = bad_record_mac
> >>
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA256
> >>
> >> George,
> >>
> >> On 10/13/15 12:35 PM, George Stanchev wrote:
> >> > [1] states: " JDK 7-9 enables SSLv2Hello on the server side only.
> >> > (Will not send, but will accept SSLv2Hellos)"
> >>
> >> Interesting. This absolutely makes sense, though, since SSL should
> >> just die. :)
> >>
> >> > I've opened support case both MS and already there is a bug filed
> >> > with Oracle on this and really, to be absolutely certain if the
> >> > issue is in Java or SChannel, one would have to write a non-Java
> >> > client that that mimics the handshake messages send from Java with
> >> > something like OpenSSL or NSS or whatever and see if the bug
> replicates.
> >>
> >> It might be doable with OpenSSL s_client or something. Tough to
> >> replicate Java's behavior with a non-Java tool, though.
> >>
> >> > Writing a Java/Java server client could still leave some doubts as
> >> > one can argue the code reuse could mask the problem - it works but
> >> > the bug on the client side is hidden by the server containing
> >> > similar/same bug so the MACs check out...
> >> >
> >> > Unfortunately I don't have the time to invest in this more than I
> 

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

[George Stanchev]

From the source of truth: sun.security.ssl.ClientHandshaker.java of the latest 
JDK 8 update 60

this.enabledProtocols = [SSLv2Hello, TLSv1, TLSv1.1, TLSv1.2]
this. maxProtocolVersion = TLSv1.2


// Not a TLS1.2+ handshake
// For SSLv2Hello, HandshakeHash.reset() will be called, so we
// cannot call HandshakeHash.protocolDetermined() here. As it does
// not follow the spec that HandshakeHash.reset() can be only be
// called before protocolDetermined.
// if (maxProtocolVersion.v < ProtocolVersion.TLS12.v) {
// handshakeHash.protocolDetermined(maxProtocolVersion);
// }

// create the ClientHello message
ClientHello clientHelloMessage = new ClientHello(
sslContext.getSecureRandom(), maxProtocolVersion,
sessionId, cipherSuites);


I just stepped through the code, there is absolutely no way to override this 
without hacking JSSE...

/sigh

George

-Original Message-
From: Aurélien Terrestris [mailto:aterrest...@gmail.com] 
Sent: Tuesday, October 13, 2015 3:41 PM
To: Tomcat Users List
Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

"Ok, may be you are ahead of me on this one, but setEnabledProtocols(), to my 
understanding does the same as the system property "jdk.tls.client.protocols". 
It gives the JSSE a pool of protocols to choose from but it will be up to JSSE 
to select the ClientHello version. I might have missed something but I spent 
quite a bit of time in the Handshaker and related classes in the JDK and 
couldn't see anything that can change that..."

Sorry, but I believe that no. To understand, you need to look to the old Ref 
Guide ( 
https://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#InstallationAndCustomization
) which in "Annex A" says that you context.getInstance() takes one argument 
called "protocol" while sslsocket.setEnabledProtocols() takes a list of 
protocols including the SSLv2Hello.
If you are about to write a TLS client using a SSLv2Hello, you will call
getInstance("TLS") and setEnabledProtocols("SSLv2").

I hope things are more understandable :)




2015-10-13 23:12 GMT+02:00 George Stanchev :

> Ok, may be you are ahead of me on this one, but setEnabledProtocols(), 
> to my understanding does the same as the system property 
> "jdk.tls.client.protocols". It gives the JSSE a pool of protocols to 
> choose from but it will be up to JSSE to select the ClientHello 
> version. I might have missed something but I spent quite a bit of time 
> in the Handshaker and related classes in the JDK and couldn't see anything 
> that can change that...
>
> George
>
> -Original Message-
> From: Aurélien Terrestris [mailto:aterrest...@gmail.com]
> Sent: Tuesday, October 13, 2015 2:55 PM
> To: Tomcat Users List
> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, 
> description = bad_record_mac
>
> "How do you force Java 8 to use SSLv2Hello?"
>
> You can do this when writing your own Java client : calling the 
> SSLSocketFactory to create an SSLSocket and configure with 
> setEnabledProtocols (
>
> https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocket.html
> #setEnabledProtocols-java.lang.String:A-
> )
>
> If you have some IIS server on internet which reproduces the problem, 
> I'll try with JTouch ( jtouch.sourceforge.net ) or write a small client.
>
>
>
>
> 2015-10-13 22:22 GMT+02:00 Aurélien Terrestris :
>
> > George,
> >
> > do you have any network capture that we can see ?
> >
> > 2015-10-13 22:10 GMT+02:00 George Stanchev :
> >
> >> >> It might be doable with OpenSSL s_client or something. Tough to
> >> replicate Java's behavior with a non-Java tool, though.
> >>
> >> I tried hard with the s_client but it can limit the protocols to 
> >> one or another but it canot mix-and-match (hello 1.2, ok we will do 
> >> 1.0) like Java
> >> 8 does. Either TLSv1 or TLSv1.2 but not both. Neither can curl 
> >> which is also on top of openssl.
> >>
> >> Today, I spent 2.5 hours with a lemming from MS getting basically 
> >> nowhere. I really need an engineer, but they give me those clueless 
> >> support people that is wasting mine and their time. If someone 
> >> knows how to escalate or a forum where MS developers hang out, I 
> >> would
> appreciate it.
> >> The support person I got today was clueless, went over a script and 
> >> any attempt to explain a little more technical details led to total 
> >> confusion and rebooting the script to beginning. Totally frustrating.
> >> At least with Oracle I got to talk with an actual engineer...
> >>
> >> George
> >>
> >>
> >> -Original Message-
> >> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> >> Sent: Tuesday, October 13, 2015 2:03 PM
> >> To: Tomcat Users List
> >> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, 
> 

RE: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description = bad_record_mac

[George Stanchev]

May be I am mistaken. I will give jtouch a try, thanks for the pointers...at 
this point I am grasping at straws :)

Thanks Aurelien!

-Original Message-
From: Aurélien Terrestris [mailto:aterrest...@gmail.com] 
Sent: Tuesday, October 13, 2015 3:52 PM
To: Tomcat Users List
Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, description 
= bad_record_mac

"Another route to try the SSLv2Hello is to hack and recompile the JSSE.
It's on my agenda to learn to do that if possible without rebuilding the whole 
JRE since for some obscure reason Oracle compiles JSSE with no debug info (and 
it is not included in the srcs distributed with the JRE) on it which makes 
debugging and inspecting local vars really hard..."

No, it's not needed. I use jtouch.sourceforge.net and it's working well for 
trying SSLv2 hello's. From the network captures, I see that it's working.
Not making advertisement for my software here, but,.. ;)







2015-10-13 23:20 GMT+02:00 George Stanchev :

> Just as a side note, https.protocols is read by HttpsUrlConnection 
> which feeds it down through setEnabledProtocols() on the SSL socket. "
> jdk.tls.client.protocols" is read directly by JSSE and does the same 
> thing...
>
> Another route to try the SSLv2Hello is to hack and recompile the JSSE.
> It's on my agenda to learn to do that if possible without rebuilding 
> the whole JRE since for some obscure reason Oracle compiles JSSE with 
> no debug info (and it is not included in the srcs distributed with the 
> JRE) on it which makes debugging and inspecting local vars really hard...
>
> George
>
> -Original Message-
> From: Aurélien Terrestris [mailto:aterrest...@gmail.com]
> Sent: Tuesday, October 13, 2015 3:13 PM
> To: Tomcat Users List
> Subject: Re: [OT] Tomcat 7.0.55/Jre 7u67: SEND TLSv1 ALERT: fatal, 
> description = bad_record_mac
>
> Maybe writing too fast..
>
> "How do you force Java 8 to use SSLv2Hello?"
>
> As suggested before, by writing your own client OR by trying this hack.
> From the JSSE Ref Guide 5, we know how to the customize the protocol ( 
> https://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefG
> uide.html#InstallationAndCustomization
> ) by setting a system property (https.protocol). Although they are no 
> more talking about this in the Ref Guide 8 ( 
> https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunPro
> viders.html#SunJSSEProvider
> ) I would give it a try as I know that the documentation is poorly written.
> I suggested 10 years ago a change in the API doc about the enabled 
> protocols, and they didn't change anything although they said they would.
>
>
>
> "[1] states: " JDK 7-9 enables SSLv2Hello on the server side only.  
> (Will not send, but will accept SSLv2Hellos)""
>
> I believe they mean "by default" as for the client side. Poorly 
> written, probably.
>
>
>
> 2015-10-13 22:55 GMT+02:00 Aurélien Terrestris :
>
> > "How do you force Java 8 to use SSLv2Hello?"
> >
> > You can do this when writing your own Java client : calling the 
> > SSLSocketFactory to create an SSLSocket and configure with 
> > setEnabledProtocols ( 
> > https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocket.ht
> > ml
> > #setEnabledProtocols-java.lang.String:A-
> > )
> >
> > If you have some IIS server on internet which reproduces the 
> > problem, I'll try with JTouch ( jtouch.sourceforge.net ) or write a small 
> > client.
> >
> >
> >
> >
> > 2015-10-13 22:22 GMT+02:00 Aurélien Terrestris :
> >
> >> George,
> >>
> >> do you have any network capture that we can see ?
> >>
> >> 2015-10-13 22:10 GMT+02:00 George Stanchev :
> >>
> >>> >> It might be doable with OpenSSL s_client or something. Tough to
> >>> replicate Java's behavior with a non-Java tool, though.
> >>>
> >>> I tried hard with the s_client but it can limit the protocols to 
> >>> one or another but it canot mix-and-match (hello 1.2, ok we will 
> >>> do 1.0) like Java
> >>> 8 does. Either TLSv1 or TLSv1.2 but not both. Neither can curl 
> >>> which is also on top of openssl.
> >>>
> >>> Today, I spent 2.5 hours with a lemming from MS getting basically 
> >>> nowhere. I really need an engineer, but they give me those 
> >>> clueless support people that is wasting mine and their time. If 
> >>> someone knows how to escalate or a forum where MS developers hang 
> >>> out, I would
> appreciate it.
> >>> The support person I got today was clueless, went over a script 
> >>> and any attempt to explain a little more technical details led to 
> >>> total confusion and rebooting the script to beginning. Totally 
> >>> frustrating. At least with Oracle I got to talk with an actual
> engineer...
> >>>
> >>> George
> >>>
> >>>
> >>> -Original Message-
> >>> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> >>> Sent: Tuesday, October 13, 2015 2:03 PM
> >>> To: Tomcat Users List
> >>> Subject: Re: