«

Hi! I'm getting into all the ssl stuff, but now I have a question about
certification chaining.
I don't really understand why this would be save. Assume I get a signed
cert from lets say VeriSign (or even was somehow able to steal one with
a private key). Now, if I would be evil, I could sign a chained
certificate with every value I want like putting microsoft in the
company flag with this cert and the open one from VeriSign. This (wrong)
certificate would be accepted by most browsers without any prompt,
because at the end of the chain is VeriSign. But my Server has really
nothing to do with microsoft!
This shouldn't be right! OR?
I know that somewhere there must be something I don't understanding
right, but where? What am I missing?

Thanks for any help...

Maik

In comp.security.ssh Maik Wiege <mswiege*nospam*@gmx.de>:
> Hi! I'm getting into all the ssl stuff, but now I have a question about
> certification chaining.
> I don't really understand why this would be save. Assume I get a signed
> cert from lets say VeriSign (or even was somehow able to steal one with
> a private key). Now, if I would be evil, I could sign a chained
> certificate with every value I want like putting microsoft in the
> company flag with this cert and the open one from VeriSign. This (wrong)
> certificate would be accepted by most browsers without any prompt,
> because at the end of the chain is VeriSign. But my Server has really
> nothing to do with microsoft!
> This shouldn't be right! OR?
> I know that somewhere there must be something I don't understanding
> right, but where? What am I missing?

Dunno what this has to do with ssh? Anyway, it won't work out
unless you control/manipulate the dns server setup in the client
system. Your browser will check the cert against reverse DNS and
bail out if these don't match, end of story.

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 4: static from nylon underwear

> Dunno what this has to do with ssh?
Sorry - misstyped that! Meant SSL of cource.
> Anyway, it won't work out
> unless you control/manipulate the dns server setup in the client
> system. Your browser will check the cert against reverse DNS and
> bail out if these don't match, end of story.
OK, I unerstand that's for Servers, but what about client
certificates (I know that they are not used that much by now, but
what if they will become obligatory for online banking for example
in the future - or what ever)? Isn't the idea of the certificat,
that I could be pretty shure who I'm talking to and doesn't the
chaining screw the whole idea up?
just thinking...

greetings
Maik

"Maik Wiege" <mswiege*nospam*@gmx.de> wrote in message
news:dadlb7$260d$...
>> Dunno what this has to do with ssh?
> Sorry - misstyped that! Meant SSL of cource.
> > Anyway, it won't work out
>> unless you control/manipulate the dns server setup in the client
>> system. Your browser will check the cert against reverse DNS and
>> bail out if these don't match, end of story.
> OK, I unerstand that's for Servers, but what about client
> certificates (I know that they are not used that much by now, but
> what if they will become obligatory for online banking for example
> in the future - or what ever)? Isn't the idea of the certificat,
> that I could be pretty shure who I'm talking to and doesn't the
> chaining screw the whole idea up?
> just thinking...
>
> greetings
> Maik
>
The key to the whole certificate idea is keeping private keys private!
You might be amazed at the effort that the certificate authorities such as
Verisign, RSA, Trust, etc.
put into guarding their private keys. If the private keys are lost or
someone invents a method
to obtain them, the whole scheme goes down the drain. As long as the private
keys are not
compromised and as long as you have turned on Certificate Validation (many
people don't),
you have some assurance that you are talking to an authenticated entity.

Ed



----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

>>>>> "MW" == Maik Wiege <mswiege*nospam*@gmx.de> writes:

>> Dunno what this has to do with ssh?
MW> Sorry - misstyped that! Meant SSL of cource.

The point was that this newsgroup is about SSH, not SSL. The two have
nothing to do with one another.

>>>>> "MH" == Michael Heiming <michael+>

> Dunno what this has to do with ssh? Anyway, it won't work out
> unless you control/manipulate the dns server setup in the client
> system. Your browser will check the cert against reverse DNS and
> bail out if these don't match, end of story.

No, browsers generally do *not* do this, for several reasons. The most
obvious is that, since the DNS is insecure, it would be easy to get a
client to incorrectly accept a certificate by simply spoofing its DNS
traffic. Browsers should (and generally do) match the certificate against
what the user types, nothing else -- that's the point, to verify that
you're connecting to the site you intended. It's also why aliases don't
work -- for example, suppose a site's certificate says www.foo.com, but
the server is reachable at foo.com as well. If you connect to
https://foo.com/ the browser will give a warning; it's up to you to decide
that a certificate with the name "www.foo.com" just as acceptable in this
case.

In any event, to answer the original question: certificate you get from
Verisign or whomever will not have the CA bit set, and hence no one will
trust a further certificate you sign with its key. The only way to get a
CA certificate from such an entity will be to enter into a legal agreement
stipulating that you *won't* do things like issue bogus certificates for
domains you don't own.

--
Richard Silverman

In comp.security.ssh Richard E. Silverman <>:
>>>>>> "MW" == Maik Wiege <mswiege*nospam*@gmx.de> writes:

> >> Dunno what this has to do with ssh?
> MW> Sorry - misstyped that! Meant SSL of cource.

> The point was that this newsgroup is about SSH, not SSL. The two have
> nothing to do with one another.

>>>>>> "MH" == Michael Heiming <michael+>

> > Dunno what this has to do with ssh? Anyway, it won't work out
> > unless you control/manipulate the dns server setup in the client
> > system. Your browser will check the cert against reverse DNS and
> > bail out if these don't match, end of story.

> No, browsers generally do *not* do this, for several reasons. The most
> obvious is that, since the DNS is insecure, it would be easy to get a
> client to incorrectly accept a certificate by simply spoofing its DNS
> traffic. Browsers should (and generally do) match the certificate against
> what the user types, nothing else -- that's the point,

Yep, that what I meant the system will check against reverse DNS,
the name you typed into the URL box, if it matches against the
so called "common name" of the certificate.

[..]

> In any event, to answer the original question: certificate you get from
> Verisign or whomever will not have the CA bit set, and hence no one will
> trust a further certificate you sign with its key. The only way to get a
> CA certificate from such an entity will be to enter into a legal agreement
> stipulating that you *won't* do things like issue bogus certificates for
> domains you don't own.


--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 120: we just switched to FDDI.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Heiming sent the following message through subspace:

> In comp.security.ssh Maik Wiege <mswiege*nospam*@gmx.de>:
>> Hi! I'm getting into all the ssl stuff,

> Dunno what this has to do with ssh?

SSL, not SSH. =

- --
Solbu - http://www.solbu.net
Remove 'ugyldig' for email
PGP key ID: 0xFA687324
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFCypcGT1rWTfpocyQRAsWhAJ9dhfxitcEwoTCUVurLyq 5dinCFWwCeLOLw
7dwnSObjcgOfCOrF7gp2ADM=
=0jBP
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Heiming sent the following message through subspace:

> the system will check against reverse DNS,
> the name you typed into the URL box, if it matches against the
> so called "common name" of the certificate.

Reverse DNS is _NOT_ the same at the url you type in the browser.

I have a webserver at home for my own private purposes.
It have 3 functional URL (or vhosts),
of which one is only accessible from within the LAN.

The 2 public URLs do NOT match the Reverse DNS opf my server
as the PTR (Reverse DNS) is provided by my ISP.

I think you are mistaken the "Reverse DNS" or PTR with an URL,
which is NOT the same.

A certificate _only_ validates the URL, not the PTR.

- --
Solbu - http://www.solbu.net
Remove 'ugyldig' for email
PGP key ID: 0xFA687324
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFCyppkT1rWTfpocyQRAkyBAJ9NxPGvIBVy58+opAwJh+ 4akUZhUACeLpX8
0+uQatOpDEHPOlIRYSWZvw4=
=d0zH
-----END PGP SIGNATURE-----

Michael Heiming wrote:

> Yep, that what I meant the system will check against reverse DNS,
> the name you typed into the URL box, if it matches against the
> so called "common name" of the certificate.

Err no. The browser matches the typed-in URL to the certificate URL. No need for
rDNS.

--
Chris S.

In comp.security.ssh Chris Salter <>:
> Michael Heiming wrote:

>> Yep, that what I meant the system will check against reverse DNS,
>> the name you typed into the URL box, if it matches against the
>> so called "common name" of the certificate.

> Err no. The browser matches the typed-in URL to the certificate URL. No need for
> rDNS.

Yep, thx for clearing up. Mixed things up, probably as you need
an IP based virtual host for SSL, but this is only because of the
https handshake happening before the http request is send so
there's no way to know the virtual host.

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 10: hardware stress fractures