Question regarding SSL/TLS

>From what I've read I've come to understand that a server will
digitally sign a certificate by first creating a hash, then encrypting
the hash using its private key. The server will then send the
digitally signed certificate to the client, who decrypts it using the
public key and compares it with the hash value it calculates for the
certificate.
What prevents an attacker from decoding the certificate, substituting
his own information, re-calculating the hash, re-encrypting it using
his own private key and sending it to the client along with a new
public key?

Re: Question regarding SSL/TLS

jois.de.vivre@gmail.com wrote:
>>From what I've read I've come to understand that a server will
> digitally sign a certificate by first creating a hash, then encrypting
> the hash using its private key. The server will then send the
> digitally signed certificate to the client, who decrypts it using the
> public key and compares it with the hash value it calculates for the
> certificate.
> What prevents an attacker from decoding the certificate, substituting
> his own information, re-calculating the hash, re-encrypting it using
> his own private key and sending it to the client along with a new
> public key?

That the verification process will fail? The client won't take the
attackers public key, but the the real certifier's key.

Re: Question regarding SSL/TLS

> That the verification process will fail? The client won't take the
> attackers public key, but the the real certifier's key.

I see, so the public key has to be known and trusted beforehand? Does
a browser then keep a list of trusted public keys?

Re: Question regarding SSL/TLS

jois.de.vivre@gmail.com wrote:
> I see, so the public key has to be known and trusted beforehand? Does
> a browser then keep a list of trusted public keys?

Yes. They are in its database when browser is installed to the computer.



--
My computer security & privacy related homepage
http://www.markusjansson.net
Use HushTools or GnuPG/PGP to encrypt any email
before sending it to me to protect our privacy.

Re: Question regarding SSL/TLS

Markus Jansson wrote:
> jois.de.vivre@gmail.com wrote:
> > I see, so the public key has to be known and trusted beforehand? Does
> > a browser then keep a list of trusted public keys?
>
> Yes. They are in its database when browser is installed to the computer.

This is very convenient, an excellent feature. Anyone with a
corresponding "trusted" private key and access to the route can perform
a MITM attack and decrypt and modify the traffic. We reach the point
where "trusted" has to be taken seriously.

Kind regards
Ludovic

Re: Question regarding SSL/TLS

Ludovic Joly wrote:
> Markus Jansson wrote:
>> jois.de.vivre@gmail.com wrote:
>>> I see, so the public key has to be known and trusted beforehand? Does
>>> a browser then keep a list of trusted public keys?
>> Yes. They are in its database when browser is installed to the computer.
>
> This is very convenient, an excellent feature. Anyone with a
> corresponding "trusted" private key and access to the route can perform
> a MITM attack and decrypt and modify the traffic. We reach the point
> where "trusted" has to be taken seriously.

Some commercial operating systems deliver such key stores as well. Hey,
I found something Windows is actually good for. :-)

Re: Question regarding SSL/TLS

Ludovic Joly wrote:
> Anyone with a
> corresponding "trusted" private key and access to the route can perform
> a MITM attack and decrypt and modify the traffic.

Only people who can do that are the ones who HAVE that key, which means
the site owners, which can decrypt the traffic anyway, so...whats your
point?

Ofcourse Verisign could sign bogus key for me for
https://www.hushmail.com but why the heck would they do that? They get
more money on publish valid certs than unvalid. Not to mention that I
can always save hushmail.com cert to my computer and compare it to the
one the "site" is offering me.

--
My computer security & privacy related homepage
http://www.markusjansson.net
Use HushTools or GnuPG/PGP to encrypt any email
before sending it to me to protect our privacy.

Re: Question regarding SSL/TLS

Markus Jansson wrote:

> Ofcourse Verisign could sign bogus key for me for
> https://www.hushmail.com but why the heck would they do that?

Because they're stupid?

Hint: The signed a key of an unknown, who called in by anonymous phone,
a cert on the company name "Microsoft Corporation". Yes, Class 3, which
normally requires a full identity verification process.

> They get more money on publish valid certs than unvalid.

No, they get money for publishing certs. Really doesn't matter if valid
or spoofed.

Re: Question regarding SSL/TLS

In article <4l1580Feb7pcU1@news.dfncis.de>,
Sebastian Gottschalk wrote:

> Markus Jansson wrote:
>
> > Ofcourse Verisign could sign bogus key for me for
> > https://www.hushmail.com but why the heck would they do that?
>
> Because they're stupid?
>
> Hint: The signed a key of an unknown, who called in by anonymous phone,
> a cert on the company name "Microsoft Corporation". Yes, Class 3, which
> normally requires a full identity verification process.
>
> > They get more money on publish valid certs than unvalid.
>
> No, they get money for publishing certs. Really doesn't matter if valid
> or spoofed.

But their reputation should be based on how well they validate certs
before publishing them. Ideally, browser vendors would not include the
certificates of CAs with bad reputations, and site owners would not
publish their certs through them. And if site owners don't publish
certs through them, they don't get money.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Re: Question regarding SSL/TLS

Barry Margolin wrote:

> But their reputation should be based on how well they validate certs
> before publishing them.

Should, should, should...

> Ideally, browser vendors would not include the certificates of CAs with
> bad reputations,

Tell it to the browser vendors. They don't care, because they're getting
paid for including the certs beside better knowledge.

> and site owners would not publish their certs through them.

Tell it to the site owners. They usually only use the certificate to get
the yellow SSL lock without getting any warnings displayed to the user.
And that's why they won't buy any secure certificates from really secure
CAs that are not included in the webbrowser.

Security really doesn't matter.

> And if site owners don't publish certs through them, they don't get money.

As you see, it's a self-supporting model of extortion and
monopolization. Up today, the cut between CAs included in the browser
and secure+trustworthy CAs is empty (or, at best, you might accept the
Staat der Nederlandern Root CA). Particularly due to VeriSign aqquiring
all previously trustworthy CAs and applying their understanding and
practices of "security".

Re: Question regarding SSL/TLS

Sebastian Gottschalk wrote:
>> They get more money on publish valid certs than unvalid.
>
> No, they get money for publishing certs. Really doesn't matter if valid
> or spoofed.

If they give out spoofed certs, they will loose credibility and rest of
their customers too.

--
My computer security & privacy related homepage
http://www.markusjansson.net
Use HushTools or GnuPG/PGP to encrypt any email
before sending it to me to protect our privacy.

Re: Question regarding SSL/TLS

Markus Jansson wrote:
> Sebastian Gottschalk wrote:
>>> They get more money on publish valid certs than unvalid.
>>
>> No, they get money for publishing certs. Really doesn't matter if
>> valid or spoofed.
>
> If they give out spoofed certs, they will loose credibility and rest
> of their customers too.

See for a discussion on that. Point
is that unaware customers and an unbroken monopolization disable the
self-regulation of a free market.