I have to agree with this logic. SSL termination devices placed in front of
web servers for the purpose of offloading the computationally expensive key
generation/exchange and/or the encryption/decryption processing are not much
more than hardware optimized web proxy servers. The key design
considerations this generates are more in the security space. I say this
because how we choose to deal with this "used to be encrypted" data after
termination is a concern that will plague the end-user of a commerce site.
dg
------------------------------------------
Douglas Gourlay
W- 415.371.2345
C- 415.269.3684
-----Original Message-----
From: hno@hem.passagen.se [mailto:hno@hem.passagen.se]
Sent: Friday, September 08, 2000 2:27 PM
To: Patrik Fältström
Cc: wrec@cs.utk.edu
Subject: Re: Middlebox Features
Patrik Fältström wrote:
> The IESG is worried about "middlebox features" which comes up all
> over the place. Just all over. The way people think about early TCP
> termination, "front-ending SSL connections so the SSL is not all the
> way to the server", ...etc might not all the time work well in todays
> design of the Internet.
I think most IP people dislike the TCP hacks quite often done today in
load balancers and "transparent" proxies & accelerators. This is bound
to give problems sooner or later (quite often sooner in my experience).
Regarding the SSL connection termination outside the "web server" I
don't view it as a problem if done properly (i.e. no TCP hacking).
Technically what is done is to introduce a HTTPS->HTTP application
gateway in the request flow. The end point the user client connects to
is the gateway application.
-- Henrik Nordström
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:29 MST