Re: SSL Problems

[Nathan Hamblen]

On 01/20/2012 06:47 AM, Peter Robinett wrote:

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.

Nathan

[Peter Robinett]

Thanks, Nathan, that's a great idea. Here's the example from one that fails:

Java spec version: 1.6

Java VM vendor: Sun Microsystems Inc.

Java VM version: 20.2-b06

Java runtime version: 1.6.0_27-b07

Scala version: 2.9.1.final

I'll keep trying to get one that succeeds!

Peter

[Peter Robinett]

I should add my development machine:

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

[Henry Story]

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.

See this work:

http://tools.ietf.org/html/draft-ietf-dane-use-cases-05

Nathan

Social Web Architect
http://bblfish.net/

[Peter Robinett]

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.

Any ideas?

Thanks,

Peter

[Peter Robinett]

Sorry, it was my mistake converting it from Java. This is the correct line:

sslContext.init(null, Array(new NaiveTrustManager()), new SecureRandom());

Nathan, do you know any way to make this process easier?

Thanks,

Peter

[Nathan Hamblen]

Does it fix the problem?

[Peter Robinett]

Sorry, yes it does, by considering all SSL certificates as valid.

[Nathan Hamblen]

On 01/25/2012 10:17 AM, Peter Robinett wrote:

Sorry, yes it does, by considering all SSL certificates as valid.

Okay, so it is a cert problem like we thought. You could add a convenience method to ConfiguredHttpClient:
https://github.com/dispatch/dispatch/blob/master/http/src/main/scala/ConfiguredHttpClient.scala

This is not something I'd ever want to enable default but I don't mind if it's easier for people who know what they are doing.

[Randall Schulz]

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...)


Randall Schulz

[Randall Schulz]

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

[Randall Schulz]

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???).


Randall Schulz

[Nathan Hamblen]

On 11/02/2012 11:16 AM, Randall Schulz wrote:
> 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.

Nathan