httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Wort <>
Subject RE: [users@httpd] New to SSL
Date Wed, 19 Mar 2003 14:25:57 GMT
On Wed, 19 Mar 2003, Boyle Owen wrote:

> >-----Original Message-----
> >From: Tim Wort []
> >
> >... In truth, even with a real
> >certificate SSL is only marginally better, most users never read the
> >certificate warning that is sent if the certificate doesn't
> >match the site...
> With the intention of informing myself more about this important and
> interesting subject, I'd like to raise a hand at this comment.
> My understanding is that, mathematically speaking, SSL is exactly as
> secure with a self-signed cert as it is with a "real" cert from a
> professional certificate authority (e.g. Verisign). What you buy when
> you buy a Verisign cert is not additional encryption power, but
> *authentication* - the browser will be able to verify that your site
> really does have the right to use that domain-name.

Your understanding is correct. By "marginally better" I meant that the
overall security with SSL is marginally better with a real certificate as
opposed to a self-signed certificate in as much as a CA (a trusted third
party) is assuring the client that the site is really who they say they
are (authentication.) With a self-signed certificate you do not have that
assurance.  Your comment is correct that the encryption is just as good
with a self-signed certificate, a CA signed certificate or even with no
certificate at all but encryption without authentication is not secure
because you cannot be sure who you are encrypting with. Thus, a
self-signed certificate is equal to no certificate and overall security is

To clarify how the authentication works: The server admins sends a public
key and information about the company and server to a CA (along with a
check), the CA verifies the information (hopefully, one CA issued a
certificate for localhost) and builds a file that includes the public key
and other information (an expiration date, going to need another check
sometime) and then the CA runs a one-way hash (like md5 or sha) against
the information, encrypts the HASH with the CA's public key and combines
this to create a certificate and sends it to the server.

The server installs this certificate and it is presented to a client on a
connections request for a SSL connection, the client gets the certificate
data in clear text along with the encrypted hash that is part of the
certificate, the client decrypts the hash with the public key of the CA
(usually built into the browser for verisign and others CAs but it can be
added to some browsers although a difficult process). Decrypting the hash
proves that the certificate is really generated by the CA. Then the client
also hashes the clear text data and compares the two hashs, if they match
it assures the integrity of the clear text data in the certificate.

> Personally, I would never type in my credit card number to a form if the
> browser was warning me that the cert and the domain-name didn't match.

That is the intention of a certificate, the client ACTUALLY reads the
boxes that open when connecting to a SSL server, they ACTUALLY examine the
certificate and verify that it is from the correct site etc.
Unfortunately most people just click right through those boxes, hell, I

> You get a lot of mails on this list and on the mod_ssl list asking, "How
> do I get SSL working - I just want encryption, I don't care about
> authentication...". I usually try to point out that it is like asking,
> "I want to send money to the bank - I want an armoured car to come and
> collect it but I don't care where the armoured car actually goes..."

In the end, after I typed all this in, I think we are probably in total
agreement here. :^)

> Rgds,
> Owen Boyle
> Disclaimer: Any disclaimer attached to this message may be ignored.
> >or if the attacker just makes up a certificate.
> >
> > While the cryptography can be attacked it's unlikely, I know
> >of no known
> >case where say a credit card number has been stolen on the internet by
> >attacking the SSL cyper. Not that it can't be done but if your
> >a attacker
> >the return on investment just isn't worth it and it is
> >probably easier to
> >hack the server and get the database of credit cards then spend hours
> >trying to decrypt the one packet that has the credit card number in it.
> >
> >
> >Bruce Schneier's last <>
> >crypto-gram (Mar 15th) has a very good erite up on the
> >relative worth of
> >SSL and information about the most resent assult to the protocol.
> >
> >
> >
> >
> >On Wed, 19 Mar 2003, Scott Taylor wrote:
> >
> >> Hello,
> >>
> >> I added my own signed certificate to this server and I'm
> >wondering if this
> >> is normal for startup or did I do something wrong/unnecessary?  It's
> >> running on Mandrake Linux 9.0.  This dialogue only shows up
> >in the log not
> >> when running the startup script /etc/rc.d/init.d/httpd start
> >>
> >> First time I thought I broke it because it just sat there
> >with "Starting
> >> HTTPD:".  It was only by reading the log did I realize it
> >was waiting from
> >> input.
> >>
> >> Well, that was months ago now.  This morning I had a
> >hardware failure and
> >> the server rebooted and just sits at the spot where httpd
> >starts up because
> >> it is waiting for user input of the pass phrase.  Is there anything I
> >> should do (should have done) different?  It's a bit of a
> >pain, but if it's
> >> the secure way to do it I guess I can come in at 2AM to
> >restart it if needs
> >> be (seldom ever happens).
> >>
> >> Cheers.
> >>
> >> <log snippet>
> >> Mar 19 02:42:34 mustang httpd: Apache-AdvancedExtranetServer/1.3.26
> >> mod_ssl/2.8.10 (Pass Phrase Dialog)
> >> Mar 19 02:42:34 mustang httpd: Some of your private key
> >files are encrypted
> >> for security reasons.
> >> Mar 19 02:42:34 mustang httpd: In order to read them you
> >have to provide us
> >> with the pass phrases.
> >> </log snippet>
> >>
> >> Scott
> >>
> >>
> >> ---------------------------------------------------------------------
> >> The official User-To-User support forum of the Apache HTTP
> >Server Project.
> >> See <URL:> for more info.
> >> To unsubscribe, e-mail:
> >>    "   from the digest:
> >> For additional commands, e-mail:
> >>
> >>
> >>
> >
> >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> >=        Inkling Research Inc.      =
> >=   =
> >=         =
> >=                                   =
> >=        Eschew Obfuscation         =
> >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> >
> >
> >
> >---------------------------------------------------------------------
> >The official User-To-User support forum of the Apache HTTP
> >Server Project.
> >See <URL:> for more info.
> >To unsubscribe, e-mail:
> >   "   from the digest:
> >For additional commands, e-mail:
> >
> >
> This message is for the named person's use only. It may contain
> confidential, proprietary or legally privileged information. No
> confidentiality or privilege is waived or lost by any mistransmission.
> If you receive this message in error, please notify the sender urgently
> and then immediately delete the message and any copies of it from your
> system. Please also immediately destroy any hardcopies of the message.
> You must not, directly or indirectly, use, disclose, distribute, print,
> or copy any part of this message if you are not the intended recipient.
> The sender's company reserves the right to monitor all e-mail
> communications through their networks. Any views expressed in this
> message are those of the individual sender, except where the message
> states otherwise and the sender is authorised to state them to be the
> views of the sender's company.
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See <URL:> for more info.
> To unsubscribe, e-mail:
>    "   from the digest:
> For additional commands, e-mail:

=        Inkling Research Inc.      =
=   =
=         =
=                                   =
=        Eschew Obfuscation         =

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message