> Given that it only happens on the server, I wonder whether it's a > runtime environment issue (I believe my app is running in Tomcat) and > already have a support ticket open with CloudBees, but I figured it > was worth asking here too in case someone has encountered similar things.
> So, any ideas?
I have had intermittent TLS problems on the JVM before, unrelated to Dispatch. Since the set of valid root certificates changes over time, your configuration can break at any time. It's awesome.
One theory I can come up with is that only 20% of the servers in your cloud are on a jvm version that recognizes the root cert that signed the remote server's cert, and the rest reject it.
Another possibility is that the remote IP address you are talking to is load balanced across servers that use different certificates, and only 20% of the time do you land on a server using a certificate that is old enough for your jvm to recgonize.
Or maybe it's a combination of the two!
I would rule out the first theory, first, by logging java.runtime.version during the request handling and then seeing if that is different for the ones that succeed vs. those that fail.
Java spec version: 1.6 Java VM vendor: Apple Inc. Java VM version: 20.4-b02-402 Java runtime version: 1.6.0_29-b11-402-11M3527 Scala version: 2.9.1.final
>> Given that it only happens on the server, I wonder whether it's a runtime environment issue (I believe my app is running in Tomcat) and already have a support ticket open with CloudBees, but I figured it was worth asking here too in case someone has encountered similar things.
>> So, any ideas?
> I have had intermittent TLS problems on the JVM before, unrelated to Dispatch. Since the set of valid root certificates changes over time, your configuration can break at any time. It's awesome.
> One theory I can come up with is that only 20% of the servers in your cloud are on a jvm version that recognizes the root cert that signed the remote server's cert, and the rest reject it.
> Another possibility is that the remote IP address you are talking to is load balanced across servers that use different certificates, and only 20% of the time do you land on a server using a certificate that is old enough for your jvm to recgonize.
> Or maybe it's a combination of the two!
> I would rule out the first theory, first, by logging java.runtime.version during the request handling and then seeing if that is different for the ones that succeed vs. those that fail.
That is an interesting point. I had such a problem some time ago. Luckily you can change the Trusted Store. It is perhaps worth doing that for each of your JVMs by using one that is distributed by a client operating system like OSX.
What is really needed is for the whole system to move to using public keys stored in DNSsec , as that would dramatically reduce this type of problem.
Well, my attempt to make it ignore all SSL errors only servered to have it reliably fail on my development machine too now.
This is what I have:
class NaiveTrustManager extends X509TrustManager { println("trust manager created")
override def checkClientTrusted(arg0: Array[X509Certificate], arg1: String) { println("Checking if the client is trusted") } override def checkServerTrusted(arg0: Array[X509Certificate], arg1: String) { println("Checking if the server is trusted") } override def getAcceptedIssuers(): Array[X509Certificate] = { println("Checking for issuers.") return null; }
}
lazy val http = new Http { def insecureClient() = { println("making insecure client")
val sslContext = SSLContext.getInstance("TLS"); sslContext.init(null, Array(new TrustManager { new NaiveTrustManager() }), new SecureRandom()); val sf = new SSLSocketFactory(sslContext, SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
val httpsScheme = new Scheme("https", sf, 443); val schemeRegistry = new SchemeRegistry(); schemeRegistry.register(httpsScheme);
val dispatch_client = new ConfiguredHttpClient(credentials) val params = dispatch_client.createHttpParams val cm = new SingleClientConnManager(params, schemeRegistry);
val client = new DefaultHttpClient(cm, params) println(client) client }
override def make_client = insecureClient()
}
Nathan or others, do you have any idea why this isn't working? My console looks like this:
making insecure client trust manager created org.apache.http.impl.client.DefaultHttpClient@36184f8 INF: [console logger] dispatch: www.westernunion.co.uk GET /WUCOMWEB/staticMid.do?method=load&countryCode=GB&languageCode=en&pagename= HomePage HTTP/1.1 javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
Basically, it looks like I'm successfully creating a new client with my trust manager but its override methods to ignore SSL errors never get called.
I tried to use Peter's code to work around what I think is the very same issue. But when I use his code (with the amended call to sslContext.init(...)), I find that while the constructor of the Http subclass is invoked, there is never a call made to insecureClient(). I find this perplexing given this line in class Http:
final val client = make_client
I'm using version 0.8.8 of Dispatch.
Can anybody enlighten me about what's going on here and how I can get the lax certificate validation to work?
(No need to explain the security implications. This is a work-around for a temporary situation while our operations team gets the expired certificates updated...)
On Thursday, 1 November 2012 14:57:24 UTC-7, Randall Schulz wrote:
> Hello,
> I tried to use Peter's code to work around what I think is the very same > issue. But when I use his code (with the amended call to > sslContext.init(...)), I find that while the constructor of the Http > subclass is invoked, there is never a call made to insecureClient(). I > find this perplexing given this line in class Http:
> final val client = make_client
> I'm using version 0.8.8 of Dispatch.
> Can anybody enlighten me about what's going on here and how I can get the > lax certificate validation to work?
> (No need to explain the security implications. This is a work-around for a > temporary situation while our operations team gets the expired certificates > updated...)
OK, I figured it out... thread.Safety contains its own override of make_client, usurping the one in the NaiveHTTP class I defined based on Peter Robinett's sample code.
(By the way, an underscore in the name of a member of a public API in a Scala library???).
On Thursday, 1 November 2012 15:04:10 UTC-7, Randall Schulz wrote:
> Hi,
> An update... I create the Http (the naive one) with thread.Safety.
> If I remove that mix-in, things work.
> Is there a solution that can be used with thread.Safety?
> Randall Schulz
> On Thursday, 1 November 2012 14:57:24 UTC-7, Randall Schulz wrote:
>> Hello,
>> I tried to use Peter's code to work around what I think is the very same >> issue. But when I use his code (with the amended call to >> sslContext.init(...)), I find that while the constructor of the Http >> subclass is invoked, there is never a call made to insecureClient(). I >> find this perplexing given this line in class Http:
>> final val client = make_client
>> I'm using version 0.8.8 of Dispatch.
>> Can anybody enlighten me about what's going on here and how I can get the >> lax certificate validation to work?
>> (No need to explain the security implications. This is a work-around for >> a temporary situation while our operations team gets the expired >> certificates updated...)
> OK, I figured it out... thread.Safety contains its own override of > make_client, usurping the one in the NaiveHTTP class I defined based > on Peter Robinett's sample code.
> (By the way, an underscore in the name of a member of a public API in > a Scala library???).
When that class was first written (in, I don't know, 2006?) "snake case" was being tried by a lot of people writing Scala. And by a lot, I mean a few of the dozens of people writing Scala.
So the idea that the original Dispatch is bucking some Scala library convention does make me chuckle; there were not enough libraries to emulate back then.
Anyway, snake case didn't catch on in Scala, mostly because we all interop with Java code and we don't want to heighten the inconsistencies for no tangible benefit.
Long story short, Dispatch 0.9+ (reboot) is all camel case.
