Add session renegotiation to SSL/TLS

[bantonsson]

The SSL/TLS support in #15402 doesn't support session renegotiation.

[sirthias]

/cc @sirthias @jrudolph

[bblfish]

I gave a talk at Scala eXchange that explains clearly the use of client certificate renegotiation "Building the Social Web with Scala and Scala-JS"
https://skillsmatter.com/skillscasts/5960-building-a-secure-distributed-social-web-using-scala-scala-js

Any idea @bantonsson how much work it is to add this? It seems like it should be simple enough to just add client certificate renegotiation. Perhaps I can do this.

I think it would require a change the http request API to contain the name of the actor at the right layer of the TLS stack so that a message for a certificate can be sent to it.

[sirthias]

The architecture for the implementation of the whole TCP <-> TLS <-> HTTP stack has changed significantly since spray. The whole thing is now fully stream-based and actors only come into play as an implementation detail for certain stream stages.

You might want to check out these related tickets for more thoughts/discussion around the SSL/TLS support: #16167, #15883

[rkuhn]

Preliminary sketch of the types (based on web-based research, so comments welcome):

sealed trait SessionRead
case class SessionNegotiated(session: SSLSession, parameters: SSLParameters) extends SessionRead
case class SessionReadData(data: ByteString) extends SessionRead

sealed trait SessionWrite
case class SessionRenegotiate(parameters: SSLParameters, invalidate: Boolean) extends SessionWrite
case class SessionWriteData(data: ByteString) extends SessionWrite

def addSSL(f: Flow[ByteString, ByteString], parameters: SSLParameters): Flow[SessionWrite, SessionRead]
def addNoSSL(f: Flow[ByteString, ByteString]) = Flow[SessionWrite].collect{case SessionWriteData(d) => d}.via(f).map(SessionReadData)

The last two will eventually be represented as standalone pieces with four ports, so the method signatures only serve to document the intent.

On the HTTP side the HttpRequestParser will have to keep track of which bytes were received with which session and reject requests that are “split” between them. The HttpRequest will include a field that holds the session that was in effect when the request was received, and the entity’s stream will need to be terminated upon renegotiation. A renegotiation will then be effected by including this request in the HttpResponse; the response itself will only be sent once the new session has been established, so that follow-up requests are delivered with the new parameters in effect.