RE: [cinjug-users] Java Browser -- proxy, authentication, and https

["Hudson, Loren (GE Infra, Aviation, Non-GE, US)" <loren.hudson@xxxxxx>]

Thanks all who responded.  I have created in HttpClient in 10 minutes more than I've created in 4 hours using the Sun APIs

 

Open Source For The Win!

 

Thanks,

Mike Hudson
MDW - Military Data Warehouse
Java Developer/Solution Architect
Sogeti Consultant
loren.hudson@xxxxxx
Desk: 513-243-3663 ~ Dialcomm: *332-3663
Cell: 513-546-4166

-----Original Message-----
From: Eric Bardes [mailto:ericbardes@xxxxxxxxx]
Sent: Wednesday, September 12, 2007 2:02 PM
To: Hudson, Loren (GE Infra, Aviation, Non-GE, US)
Cc: users@xxxxxxxxxx
Subject: Re: [cinjug-users] Java Browser -- proxy, authentication, and https

There is a post about using the Apache Commons library which I must agree with.  So unless there are specific policy restrictions against using it, I would.

SSL introduces some new problems.  One of the goals of SSL in addition to encrypting the data is to validate the remote endpoint of a connection.  The remote endpoints sends a certificate to the browser which validates the certificate against a hard-coded list of certificate agencies distributed with the browser.

When you connect through a proxy server, the proxy server must have a mechanism can not interfere with the SSL session otherwise SSL can not be used validate the endpoint and SSL would not be able to protect the data transport.

Most proxy servers add an HTTP method called CONNECT in addition to GET and POST.  The first part of the connection is done non-SSL and the second part is then SSL.  The web browser connects to the proxy server in the clear and sends a request to the proxy server something
like:

CONNECT https://www.ecommerce.com:443/purchase HTTP/1.0
Proxy-Authorization: <AUTH-STRING>

The proxy server parses the HTTP headers and then has to provide a transparent connection between the browser (which switches to SSL at this point) and the remote site specified in the header.

--
Cheers,
Eric Bardes