On 8 Dec 2002, Waitman C. Gobble, II wrote:
> Sorry if this is all OT, however I think a key based authentication
> method with squid could be useful. Some decisions remain.
Fully agree. Problem is that to implement such a thing you also need to
implement support in the browsers.
As it is Squid is pretty much limited to the capabilities supported by the
users browsers.
[PGP and SSL]
> I believe that the ideas are similar. In the SSL model, the traffic is
> encrypted using asymmetric keys (essentially). The CA plays a part in
> validating the authenticity of the key. In the PGP model, the exchange
> is similar however there really isn't a CA.
Sidenote: SSL also includes a NULL crypto if you only want to use it for
authentication and sealing. However, for security reasons most
implementation have this very weak SSL chipher disabled.
> The HTTP stream need not be encrypted necessarily (SSL:443) for
> authentication on the proxy.
Very true.
One important aspect to note here is that the SSL authentication occurs
outsite of HTTP.
SSL is a protocol of it's own carrying out the task of authentication,
message integrity and encryption. https it HTTP ontop of SSL.
> I suppose one issue is "if" we need to depend on an authority to trust
> the signature.
To be able to tell if we trust a signature or not we must furst be able to
receive the signature.
HTTP as of today does not include support for public key based
authentication. For this task SSL is the tool available.
This leaves us with two options
a) Use SSL. However, as of today I know of no browsers supporting the use
of SSL to proxies.
b) Specify a new HTTP authentication scheme and have this scheme
implemented in both Squid and the applicable browsers.
> The new system will need to operate along with traditional methods,
> otherwise implementation would be extremely difficult. Also, it needs to
> support multiple key techniques, so one could have a choice of GPG, PGP,
> etc.
Sure. HTTP is extensible, and you may add new authentication methods. As I
said specifying a new PGP or other public key based authentication sheme
for HTTP should not be very difficult. The Digest HTTP authentication
scheme can be used as a boilerplate on how many of the problems can be
solved in the HTTP protocol.
The hard part is to get the authentication protocol accepted. For
political reasons I think a non-hierarchical digital signature based
protocol will have a very hard time to gain acceptance by the commercial
players in the next years.
> I believe that the use of public RFC's, open source software, and a set
> of carefully considered existing open source projects could set a
> standard, agreed method. Perhaps the way we have come to know and use
> DNS and HTTP came about in a similar method. If companies invest in
> commercial implementations, the more the merrier.
Fully agree.
> I would like to figure out the details and get squid to work with the
> authentication method, both as an initial experiment and as a model.
>
> I am looking at the way GPG/PGP has been integrated with existing
> products, but I see some milestones that need to be reached.
>
> I can also see that this authentication method would work well with mail
> services. It could definitely put a new twist on spam.
Which makes the more reasons to look at PGP certificate integration into
HTTP.
Regards
Henrik
Received on Sun Dec 08 2002 - 15:58:25 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:11:55 MST