Simple Https

[kreid]

Hello,

I am trying to write a simple HTTPS client to connect to a webservice hosted at https://sws-crt.cert.sabre.com using the SimpleServerClient example posted here.  I've only changed the url as seen below:

  (httpClient ? HostConnectorSetup("sws-crt.cert.sabre.com", 443, sslEncryption = true)(system, sslEngineProvider)).mapTo[HostConnectorInfo].foreach { info =>

    //println(s"Got connector: $info. Ssl encryption is ${info.setup.settings.get.connectionSettings}")

    val pipeline = sendReceiveWithRedirect(info.hostConnector)

    val req = <someRequest></someRequest>

    pipeline{

     Post("/",req)

    }

Here is what I am seeing in the logs:

[DEBUG] [01/07/2014 13:43:20.548] [system-akka.actor.default-dispatcher-5] [akka://system/user/IO-HTTP/host-connector-0/0] Attempting new connection to sws-crt.cert.sabre.com:443

[DEBUG] [01/07/2014 13:43:20.567] [system-akka.actor.default-dispatcher-3] [akka://system/user/IO-HTTP/group-0/0] Attempting connection to sws-crt.cert.sabre.com/151.193.52.22:443

[DEBUG] [01/07/2014 13:43:20.765] [system-akka.actor.default-dispatcher-5] [akka://system/system/IO-TCP/selectors/$a/0] Attempting connection to [sws-crt.cert.sabre.com/151.193.52.22:443]

[DEBUG] [01/07/2014 13:43:20.875] [system-akka.actor.default-dispatcher-5] [akka://system/system/IO-TCP/selectors/$a/0] Connection established to [sws-crt.cert.sabre.com/151.193.52.22:443]

[DEBUG] [01/07/2014 13:43:20.882] [system-akka.actor.default-dispatcher-3] [akka://system/user/IO-HTTP/group-0/0] Connected to sws-crt.cert.sabre.com/151.193.52.22:443

[DEBUG] [01/07/2014 13:43:20.887] [system-akka.actor.default-dispatcher-2] [akka://system/user/IO-HTTP/host-connector-0/0] Connection to sws-crt.cert.sabre.com:443 established, dispatching 1 pending requests

[DEBUG] [01/07/2014 13:43:20.899] [system-akka.actor.default-dispatcher-2] [akka://system/user/IO-HTTP/host-connector-0/0] Dispatching POST request to / across connection Actor[akka://system/user/IO-HTTP/group-0/0]

[DEBUG] [01/07/2014 13:43:22.173] [system-akka.actor.default-dispatcher-5] [akka://system/user/IO-HTTP/group-0/0] Received unexpected Tcp.PeerClosed, invalidating SSL session

[DEBUG] [01/07/2014 13:43:22.236] [system-akka.actor.default-dispatcher-5] [akka://system/user/IO-HTTP/group-0/0] Stopping connection actor, connection was ErrorClosed(Peer closed SSL connection prematurely)

[WARN] [01/07/2014 13:43:22.270] [system-akka.actor.default-dispatcher-2] [akka://system/user/IO-HTTP/host-connector-0/0] ErrorClosed(Peer closed SSL connection prematurely) in response to POST request to / with no retries left, dispatching error...

[DEBUG] [01/07/2014 13:43:22.280] [system-akka.actor.default-dispatcher-2] [akka://system/user/IO-HTTP/host-connector-0/0] Delivering Status.Failure for POST request to /

ERROR: spray.can.Http$ConnectionException: ErrorClosed(Peer closed SSL connection prematurely)

[DEBUG] [01/07/2014 13:43:24.577] [system-akka.actor.default-dispatcher-3] [EventStream] shutting down: StandardOutLogger started

Any idea what is going on? We are using scala 2.10, spray 1.1-RC3 and akka 2.1.4.

Thanks.

[Johannes Rudolph]

Hi,

On Tue, Jan 7, 2014 at 8:15 PM, kreid <k.o....@gmail.com> wrote:
> [DEBUG] [01/07/2014 13:43:22.173] [system-akka.actor.default-dispatcher-5]
> [akka://system/user/IO-HTTP/group-0/0] Received unexpected Tcp.PeerClosed,
> invalidating SSL session

I can reproduce the issue. The problems is this:

a) the server sends this response:

HTTP/1.1 500 Internal Server Error
SOAPAction: ""
Content-Type: text/xml;charset=utf-8
Date: Wed, 08 Jan 2014 11:53:38 GMT
Connection: close
Server: SWS

<?xml version="1.0" encoding="UTF-8"?>
<soap-env:Envelope
xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"><soap-env:Header/><soap-env:Body><soap-env:Fault><faultcode>soap-env:Client.InvalidEbXmlMessage</faultcode><faultstring>Unable
to create envelope from given source:
com.sun.xml.messaging.saaj.soap.dom4j.ElementImpl cannot be cast to
com.sun.xml.messaging.saaj.soap.Envelope</faultstring><detail><StackTrace>javax.xml.soap.SOAPException:
Unable to create envelope from given source:
com.sun.xml.messaging.saaj.soap.dom4j.ElementImpl cannot be cast to
com.sun.xml.messaging.saaj.soap.Envelope</StackTrace></detail></soap-env:Fault></soap-env:Body></soap-env:Envelope>

b) and then closes the TCP connection directly without going through
the mandatory SSL shutdown sequence which must be handled like a TCP
connection reset.

The response which, in fact, was already received cannot be used
because it contains no `Content-Length` header which means the entity
is bounded by a regular TCP close. However, as the server doesn't
implement SSL correctly the connection is never closed correctly. This
situation isn't distinguishable from a truncation attack so I don't
there's not much we can do on the spray side to fix the issue.

Incidentally, I filed an issue to simplify debugging SSL issues by
making the SslTlsSupport.tracing a regular configuration flag. Right
now, you have to recompile to get enough debug output to analyze
issues like this one.

https://github.com/spray/spray/issues/750

--
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

[kreid]

Thank you for replying.  I have a few questions:

1.  Can you provide more details of how you were able to see the response information?  You said I need to recompile.  Can you expand on this?

2.  The soap response makes sense since the request I posted in the original post is invalid.  However, things still fail with a valid request. [ErrorClosed(Peer closed SSL connection prematurely)]. I am able to get it working using play.api.libs.ws.WS.url(url).post(XML.loadString(req)) but I'd rather use Spray.  Is there a possible workaround?

As a side note, we met at Scala Days in NYC. About 4 of us went out for pizza one night after the conference.  I hope all is well.

[Johannes Rudolph]

On Wed, Jan 8, 2014 at 6:00 PM, kreid <k.o....@gmail.com> wrote:
> Thank you for replying. I have a few questions:
>
> 1. Can you provide more details of how you were able to see the response
> information? You said I need to recompile. Can you expand on this?

I pushed the branch I tested it on, see here:
https://github.com/jrudolph/spray/commit/2b31f6a4b46ca5abf713fc76c05e95db52509641

> 2. The soap response makes sense since the request I posted in the original
> post is invalid. However, things still fail with a valid request.
> [ErrorClosed(Peer closed SSL connection prematurely)]. I am able to get it

> working using play.api.libs.ws.WS..url(url).post(XML.loadString(req)) but

> I'd rather use Spray. Is there a possible workaround?

If the server isn't implementing SSL correctly (and that's what it
looks like) not sure if we can do something about it. I'll think about
it the next days.

> As a side note, we met at Scala Days in NYC. About 4 of us went out for
> pizza one night after the conference.

Yep, cool, didn't recognize you from the email. I'll send you a private mail.

[kreid]

I took a look Play's implementation and this is what they are doing under the covers:

 new com.ning.http.client.AsyncHttpClient().preparePost(url).addHeader("Content-Type","text/xml").setBody(req).execute 

Hopefully this will help with your investigation.

Thanks.

[Johannes Rudolph]

Yes, thanks, this will certainly help.

--

[Johannes Rudolph]

Hi,

I simulated a possible truncation attack (close the TCP connection
before the complete message was sent, which is what a MITM attacker
could do as well) with several clients (chrome, firefox, netty,
openssl, curl) and I found none that is as strict as spray. I guess
the problem is that the SSL/TLS and HTTPS specs are not explicit
enough about how to handle a possible truncation.

From RFC 2818 [1]:

Note that a premature close does not call into question the
security of the data
already received, but simply indicates that subsequent data might
have been truncated.
Because TLS is oblivious to HTTP request/response boundaries, it is
necessary to examine
the HTTP data itself (specifically the Content-Length header) to
determine whether
the truncation occurred inside a message or between messages.

So, I guess we should reconsider our position and make it configurable
in our SSL implementation how to handle possible truncations. I
created a ticket to track this [2].

Johannes

[1] http://tools.ietf.org/html/rfc2818#section-2.2
[2] https://github.com/spray/spray/issues/756

On Fri, Jan 10, 2014 at 4:03 PM, kreid <k.o....@gmail.com> wrote:

--