hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julius Davies" <juliusdav...@gmail.com>
Subject Re: Certificateless SSL
Date Fri, 01 Dec 2006 21:06:35 GMT
Hi, Jake,

Roland is right.  Your reference to "Client Certificate" sent me on a
journey.  :-)

Thanks for running the not-yet-common-ssl "Ping" test!  Sorry to make
you edit out so much information from the cut & paste.

Anyway, you're exactly right.  Your issue is that HttpClient is not
trusting that self-signed certificate.  java.net.URL wouldn't trust
it, either.  You have several options:

1.  Import self-signed cert into Java's "cacerts" file.
-------------------------------------------------------------------------
You can use "openssl s_client" or "not-yet-commons-ssl.jar Ping" to
download the self-signed certificate.  Cut & paste the Base64 PEM text
into a separate file (be sure to include the ----BEGIN----- and
-----END-----).  Try and import it into Java's "cacerts" file.  It's
usually found here:

$JAVA_HOME/jre/lib/security/cacerts

Here's the command to import a Base64 PEM certificate into that file:

cd $JAVA_HOME/jre/lib/security
$JAVA_HOME/bin/keytool -import -file [file.pem] -keystore cacerts

The password is usually "changeit" (unless you changed it?  ROTFL).

Personally, I don't really recommend this approach.  But it's good to
know about.  If you ever upgrade your JVM or switch to JRockit or IBM,
you're going to have to do this all over again.


2.  Use EasySSLSockeyProtocolFactory
-------------------------------------------------------------------------
http://jakarta.apache.org/commons/httpclient/sslguide.html

This is a great approach for a dev environment, but it's usually not
appropriate for a production environment.


3.  Use AuthSSLSockeyProtocolFactory
-------------------------------------------------------------------------
Set the client JKS to null.  Set the trust JKS to a brand new JKS you
created only containing the server's self-signed certificate.


4.  You can also try the ALPHA "not-yet-commons-ssl.jar"
-------------------------------------------------------------------------
I think this is an interesting approach:

http://juliusdavies.ca/commons-ssl/TrustExample.java.html

It's kind of a hybrid approach of #1 and #2.  Essentially equivalent
to #3, but without the hassle of creating a JKS file.  (Java Keystore
File).

-------------------------------------------------------------------------

Security note:  downloading the certificate directly from the SSL
handshake using "openssl s_client" or "not-yet-commons-ssl.jar" is not
safe.  In a dev environment it's okay.  But in a production
environment it leaves you suspectible to the oft-cited
man-in-the-middle.  It's safer than EasySSLSockeyProtocolFactory
because you only download the certificate one time, whereas
EasySSLSockeyProtocolFactory is always vulnerable, with every socket
created.  But nonetheless you should try to acquire the self-signed
certificate through a different medium, maybe email (with
encryption?), fax, telephone, letter mail, usb-drive, etc.  Or if the
self-signed cert is hosted on an properly signed "https" site, that's
also okay (e.g. https://trustedsite.com/path/to/self-signed.pem).

yours,

Julius



On 12/1/06, Richard Suematsu <richards@syncadd.com> wrote:
> Hi Jake,
>
> When you hit the 3rd party app, does IE give you a Security Alert box
> that says "The security certificate was issues by a company you have
> chosen not to trust. View the certificate..."
>
> If so, what thats saying is that the certificate on the server was
> signed by a CA that IE doesn't know about.  Click on the View
> Certificate button and look at the Issued by: field.
>
> Your HttpClient connection is dying because the server has an
> unrecognized CA and HttpClient can't just pop up a window asking the
> user to continue like IE.
>
> Check out: http://jakarta.apache.org/commons/httpclient/sslguide.html
>
> About half way down the page there is a EasySSLSockeyProtocolFactory
> that will allow HttpClient to ignore unrecognized CAs.
>
> Jake C wrote:
> > Thanks for the quick reply!
> >
> > Maybe I'm misunderstanding the exception I'm getting. IE is normally
> > used to access the 3rd party application, and it does NOT require us
> > to install or even select a certificate. It DOES prompt us to accept
> > THEIR certificate. We certainly don't have to generate a certificate
> > and install it in a keystore for every client.
> >
> > The exception I'm getting in HttpClient is:
> >
> > [INFO] HttpMethodDirector - I/O exception
> > (javax.net.ssl.SSLHandshakeException) caught when processing request:
> > sun.security.validator.ValidatorException: PKIX path building failed:
> > sun.security.provider.certpath.SunCertPathBuilderException: unable to
> > find valid certification path to requested target
> >
> >> From what I saw in the mailing list archives, and from a Google
> >> search, that
> > meant that I didn't have a certificate installed in JSSE.
> >
> > Here is what I get when running the ping utility:
> >
> > Writing:
> > ================================================================================
> >
> > HEAD / HTTP/1.1
> > Host: <IIS Server>
> >
> > Reading:
> > ================================================================================
> >
> > HTTP/1.1 200 OK
> > Content-Length: 1433
> > Content-Type: text/html
> > Content-Location: https://<IIS Server>/iisstart.htm
> > Last-Modified: Sat, 22 Feb 2003 02:48:30 GMT
> > Accept-Ranges: bytes
> > ETag: "<ETag>"
> > Server: Microsoft-IIS/6.0
> > X-Powered-By: ASP.NET
> > Date: Fri, 01 Dec 2006 17:02:43 GMT
> >
> > Server Certificate for: [<IIS Server>:443]
> > ================================================================================
> >
> > <IIS Server>
> > Valid: 2006/Nov/30 - 2007/Nov/30
> > s: CN=<IIS Server>, OU=<My Department>, O="<My Company>, Inc.",
L=<My
> > State>, ST=<My City>, C=US
> > i: CN=<IIS Server>, DC=<My Company>, DC=com
> > -----BEGIN CERTIFICATE-----
> > <Lots of certificate info>
> > -----END CERTIFICATE-----
> >
> > Thanks again for your quick reply, and your help!
> >
> >> From: "Julius Davies" <juliusdavies@gmail.com>
> >> Reply-To: "HttpClient User Discussion"
> >> <httpclient-user@jakarta.apache.org>
> >> To: "HttpClient User Discussion" <httpclient-user@jakarta.apache.org>
> >> Subject: Re: Certificateless SSL
> >> Date: Thu, 30 Nov 2006 23:21:23 -0500
> >>
> >> Hi, Jake,
> >>
> >> I'll take a stab at this one!
> >>
> >> Certificates don't really have much to do with encryption.
> >> Certificates address the issue of trust.  Think about it this way:
> >>
> >> How do I know I'm actually talking to "https://web.da-us.citibank.com/"?
> >>
> >> That's why they're called "certificates".  They really are like a
> >> virtual piece of paper, nicely framed, with a nice stamp and some
> >> ribbons, hanging on your Doctor's office wall.  "I guess he really
> >> must be a doctor, because few people have access to those fancy
> >> ribbons!"
> >>
> >> The "trust" works for a few reasons:
> >>
> >> - Only Citibank will be able to obtain a certificate for
> >> "citibank.com" from a root certificate authority (like thawte,
> >> verisign, many others pre-loaded into your browser).
> >>
> >> - (Or, alternatively, if Citibank can't get a certificate for
> >> "citibank.com", they'll choose a different domain name, and print that
> >> on all their marketing materials).
> >>
> >> - Once Citibank has obtained that first certificate no-one else will
> >> be able to acquire a new one for the domain, even after the first one
> >> expires.
> >>
> >> The fact that the ROOT CA's already trusted by your browser came
> >> pre-loaded is important.  This means those CA's were installed
> >> "out-of-band" - through a different medium compared to that through
> >> which you are conducting your online business.  In the case of IE6
> >> those root CA's presumably came on the CD-ROM that came with Windows
> >> XP, and NOT over the internet.
> >>
> >> (You can then use those out-of-band root ca's to bootstrap your
> >> acquisition of additional ca's.  You now have at least a few (quite a
> >> few) https:// sites you already trust, and those can provide you with
> >> additional root ca's.  This makes me think that all Firefox downloads
> >> should be over https, since that is one way we acquire new ROOT ca's -
> >> by downloading a new browser!....  anyway, confusing digression, you
> >> can give this paragraph a few months to sink in.)
> >>
> >> There's quite a lot of detail behind all of this.  For example, how
> >> does the "citibank.com" certificate get associated with those ROOT
> >> CA's already loaded in the browser?  If someone managed to temporarily
> >> steal the "citibank.com" domain, why can't they also just steal the
> >> certificate off of Citibank's website?  How does the domain name fit
> >> into all this?  For now let's just assume all this stuff is okay.
> >>
> >> Client certificates provide exactly the same service.  But now it's a
> >> question of "how does the server really know that Julius Davies is
> >> driving that browser?"  Usually a username/password is considered
> >> adequete, so client certificates are quite rare.  But they do create a
> >> 2nd factor of authentication.  Client certificates could be used to
> >> dramatically reduce phishing attacks.  But it's impractical.  The
> >> thing that's so great about client certs is that they make it harder
> >> for the public at large to access a given site.  The "public" must get
> >> a username/password, and then they must also acquire a unique client
> >> cert, install it, and regularly update it because of its expiry cycle!
> >> As much as CitiBank wants to avoid phishing, they also want their
> >> customers to be able to access the website without clogging the phone
> >> lines.
> >>
> >> Just like anything, client certs (and server certs) never provide a
> >> 100% bulletproof solution.  The private key behind the public
> >> certificate can be stolen, just like the keys to your house can be
> >> stolen.  A safe that's impossible to open is not useful.  A safe that
> >> can be opened can also be opened by the wrong person.
> >>
> >> But client certs do add one more layer of hassle to the bad guy's
> >> life.  "Great, not only do I need to get his username and password, I
> >> need to get the private key that goes with his client certificate."
> >>
> >>
> >> Onto your question:  if IIS is configured to require client certs from
> >> HTTPClient, then I suspect it's also requiring client certs from your
> >> browser.  Your browser might just not be telling you that it's sending
> >> the client cert.  Are you using Firefox?  By default Firefox won't
> >> bother prompting you to select the client certificate to use.  Firefox
> >> will just automatically provide it to the server.  But you can get
> >> Firefox to always prompt by changing the settings.
> >>
> >> (Interesting side note:  if Firefox is just automatically providing
> >> it, that means that the client cert is ultimately protected only by
> >> your screensaver password.  People probably can't "export" the client
> >> cert to a file without a special admin password, but they can still
> >> just sit down at your computer and start using the browser. But I
> >> think that's the right way to go.  In the long run (5 years from now?)
> >> that initial-logon/screensaver password is going to be the only
> >> password you ever use.)
> >>
> >> Perhaps you can try downloading "not-yet-commons-ssl.jar" from
> >> http://juliusdavies.ca/commons-ssl/.  There is a useful "ping" utility
> >> there to try and help debug HTTPS issues.  Can you try running this
> >> test?
> >>
> >> java -jar not-yet-commons-ssl.jar -t [IIS IP]:port
> >>
> >> If you recieve this response, then, yeah, your server wants a client
> >> certificate:
> >>
> >> javax.net.ssl.SSLHandshakeException: Received fatal alert:
> >> bad_certificate
> >>
> >>
> >> I have to signoff now.  But I'll be able to respond with part 2
> >> tomorrow.  Sorry I haven't answered all your questions yet.
> >>
> >> yours,
> >>
> >> Julius
> >>
> >>
> >>
> >>
> >> On 11/30/06, Jake C <buddhabuddy@hotmail.com> wrote:
> >>> I am a complete SSL noob, so please pardon me if my questions are
> >>> silly...
> >>> :-) I've seen similar questions in the archive, but nothing that really
> >>> spelled it out.
> >>>
> >>> We need an encrypted connection to a 3-rd party application, but we
> >>> don't
> >>> need validation. The data being transmitted is validation enough for
> >>> us.
> >>> However, the application we are sending to (running on Windows under
> >>> IIS) is
> >>> requiring a certificate.
> >>>
> >>> I know it is possible to use SSL without requiring a certificate, as
> >>> the
> >>> test application at the bottom of the HttpClient SSL Guide works for
> >>> Verisign, but not for our application.
> >>>
> >>> I see two possible ways of getting around this, and I'd just like some
> >>> validation that these would work the way I want (not requiring our
> >>> users to
> >>> mess with certificates).
> >>>
> >>> 1) Use an Authenticating Proxy Server. We should be able to set up
> >>> one of
> >>> these that accepts SSL connections without requiring a certificate, and
> >>> configure the connection between it and our 3-rd party application
> >>> using a
> >>> certificate just for the proxy server, and not for each individual
> >>> client.
> >>>
> >>> 2) Modify the IIS configuration of our 3-rd party application so
> >>> that it
> >>> doesn't require client certificates, as the data being sent contains
> >>> the
> >>> real authentication information. I"m not sure this is really an
> >>> option, as I
> >>> don't know IIS at all. We DO have access to the server, though.
> >>>
> >>> Do both of these methods work, and encrypt our data? If so, is the
> >>> encryption in the second case just as strong as if we used client
> >>> certificates, or is it weaker because there is only a server
> >>> certificate? Is
> >>> there any other method I missed?
> >>>
> >>> The application we are accessing initially provides a login page,
> >>> and we
> >>> just provide a MethodPost with the needed data, so the SSL
> >>> Connection itself
> >>> isn't initially authenticated. What I don't really understand is how a
> >>> generic web browser certificate is any better than no certificate at
> >>> all.
> >>> Why is a personal certificate required via HttpClient and not via a web
> >>> browser?
> >>>
> >>> _________________________________________________________________
> >>> Get FREE company branded e-mail accounts and business Web site from
> >>> Microsoft Office Live
> >>> http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail:
> >>> httpclient-user-help@jakarta.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> yours,
> >>
> >> Julius Davies
> >> 416-652-0183
> >> http://juliusdavies.ca/
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> >>
> >
> > _________________________________________________________________
> > All-in-one security and maintenance for your PC.  Get a free 90-day
> > trial!
> > http://clk.atdmt.com/MSN/go/msnnkwlo0050000002msn/direct/01/?href=http://clk.atdmt.com/MSN/go/msnnkwlo0050000001msn/direct/01/?href=http://www.windowsonecare.com/?sc_cid=msn_hotmail
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> >
> >
> >
>
>
> --
> Aloha,
> Richard Suematsu
> SynCaDD Systems, Inc.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>


-- 
yours,

Julius Davies
416-652-0183
http://juliusdavies.ca/

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org


Mime
View raw message