[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jetty-users] Encryption of the HTTP protocol (e.g. not its payload)
|
Hi,
On Fri, Dec 20, 2019 at 12:22 AM Karel Goderis <karel.goderis@xxxxxx> wrote:
>
> All,
>
> I have an embedded server that running a ServletContextHandler. The client and server first exchange a bunch of HTTP 1.1 based messages to negotiate an encryption key, which is subsequently used to encrypt the stream of data that is exchanged. That is, it is not the HTTP payload of subsequent messages that is encrypted, but the complete stream itself is encrypted.
That is exactly the description of what TLS does.
Is there a reason why you can't use TLS from the beginning (which is
far better scrutinized with respect to security than using a custom
protocol)?
> e.g. the protocol somehow “morphs” into something “different" using the same TCP port number. How can this be implemented?
Your best option is to use TLS from the beginning.
If you really cannot, EndPoint.upgrade() is the mechanism to use.
What you want to do is to something similar to what happens with
WebSocket: it starts with HTTP/1.1 and then morphs into WebSocket.
HttpConnection has already built-in the mechanism to upgrade.
HttpConnection.onCompleted() is called when a HTTP/1.1
request/response is completed.
It then calls HttpConnection.upgrade() to see if it must upgrade the
connection by searching the new connection as a request attribute.
What you want to do is to write your new connection, store it as an
attribute in the HTTP request, and Jetty will do the rest for you.
https://github.com/eclipse/jetty.project/blob/jetty-9.4.24.v20191120/jetty-server/src/main/java/org/eclipse/jetty/server/HttpConnection.java#L374.
--
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
