Re: [jetty-users] Encryption of the HTTP protocol (e.g. not its payload)

[Karel Goderis <karel.goderis@xxxxxx>]

>> 
> 
> Then you have to explain better how HAP works.
> Jetty can handle bytes _before_ HTTP/1.1 requests (e.g.
> ProxyConnectionFactory), it can handle sniffing bytes to figure out
> what protocol to use (e.g. OptionalSslConnectionFactory), and it can
> handle upgrades _after_ HTTP/1.1 (e.g. WebSocket).
> The EndPoint.upgrade() mechanism uses the same connection, there is no
> new connection creation.
> 
> My pointer shows how the server upgrades the Jetty Connection object
> on an existing EndPoint - it's what happens on server side.
> The Jetty Connection object is what interpret the bytes from the network.
> You start with HttpConnection that interprets HTTP/1.1 and you upgrade
> to your HAPConnection that interprets HAP.
> The TCP connection remains the same, what changes is only how you
> interpret the network bytes.


I just went through some docs, and the logical thing to do would indeed be to create new type of ConnectionFactory that creates Connections that contain a symmetrical encryption key that can be used to encode/decode bytes in Connection. Once the encrypted data flows, there is no way to figure out the protocol to use (unless, I assume that anything that is not HTTP, is in fact encrypted)

HAP does a stepped exchange of HTTP payload through a standard path, and then, when that setup completes, it starts to send data (to the same TCP port) in an encrypted fashion. From what I sense (because not described well in the specs) is that the whole stream has to be decrypted, and will be in fact a “standard” HTTP 1.1 message with a URL path and all, which then has to go to the correct servlet/handler. 

Will look into it
Tx
K