The ony other issue one really has that Owen has not covered, is trsting
the issuing CA to do things correctly. There's an incident not too long in
the past whence a site not Microsoft affilliated obtained a fake microsoft
cert. Of course there are also man in the middle exploits, even with ssl
and ssh, though they tend to be rare and hard to impliment, for the most
part. With wireless being the new toy in use by many, there are issues of
information leakage too, but these are different topics in and of
themselves...
Cool writeup Owen, we;re saving it here to send out as common requests
come in.
Thanks,
Ron DuFresne
On Tue, 7 May 2002, Owen Boyle wrote:
> Steve Leach wrote:
> >
> > Owen,
> >
> > I just followed this thread - thanks for that condensed 'how it works' for
> > certificates - I picked up two things I did not know, and as they say
> > knowledge is power :)
> >
> > I am wondering at the last statement as to whether the limitation lies in
> > the ability to produce a certificate that could verify all hosted domains,
> > or whether Apache (or indeed any HTTPS server) could work with such a
> > beast?
>
> As I understand it, the trouble is that there are two aspects to SSL:
> encryption and authentication. If it was only about encryption, you
> wouldn't have to tie your certificates to the different sites - so you
> could just serve up a general server-certificate which would contain
> your public key (which is, after all, just a big long number). The
> client would use this to send you a session-key and you'd have
> established the secure channel. Then you could exchange the HTTPS
> packets in confidence and use the "Host:" fields therein to select
> virtualhosts. Indeed, this is what happens when people naively set up
> NBVHs on port 443 - the server just uses the certificate from the first
> VH for any request it receives.
>
> However, we've forgotten about authentication. If you really want a
> secure connection, it is no use just encrypting the datastream; you have
> to be sure that the packets are really going to the destination you
> want. If you send your credit card details to www.amazon.com how can you
> be sure that the server at the other end really does belong to Amazon
> Books Inc. and is not a fake server with a copy of their site and that
> some crook has not hijacked a router somewhere along the way? The answer
> is that when you get the cert from amazon.com it contains not only the
> public key but also their site name. Their cert has also been signed by
> Verisign or somesuch and so can be verified.
>
> Now you can't just make a self-signed cert which says you're amazon.com
> because "the browser does not recognise the authority which signed this
> certificate".
>
> Really, these "problems" are all client-side. The server is only
> interested in setting up a secure channel so will use any cert that
> seems appropriate. The trouble only starts when the browser starts
> checking out the cert and finds that it can't verify it because the
> signing authority is unknown or that it looks fishy because the
> site-name on the request doesn't match the site-name in the cert. This
> is really just the browser manufacturers protecting you from being
> conned and themselves from being sued.
>
> Rgds,
>
> Owen Boyle.
> ______________________________________________________________________
> Apache Interface to OpenSSL (mod_ssl) www.modssl.org
> User Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
admin & senior security consultant: sysinfo.com
http://sysinfo.com
"Cutting the space budget really restores my faith in humanity. It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation."
-- Johnny Hart
testing, only testing, and damn good at it too!
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
