simple question about certificate chains

Discussion in 'Computer Security' started by Maik Wiege, Jul 5, 2005.

  1. Maik Wiege

    Maik Wiege Guest

    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
    Maik Wiege, Jul 5, 2005
    #1
    1. Advertising

  2. 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
    Michael Heiming, Jul 5, 2005
    #2
    1. Advertising

  3. Maik Wiege

    Maik Wiege Guest

    > 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, Jul 5, 2005
    #3
  4. "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 =----
    Edward A. Feustel, Jul 5, 2005
    #4
  5. >>>>> "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 <>


    > 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
    Richard E. Silverman, Jul 5, 2005
    #5
  6. 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 <>


    > > 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.
    Michael Heiming, Jul 5, 2005
    #6
  7. Maik Wiege

    Solbu Guest

    -----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)

    iD8DBQFCypcGT1rWTfpocyQRAsWhAJ9dhfxitcEwoTCUVurLyq5dinCFWwCeLOLw
    7dwnSObjcgOfCOrF7gp2ADM=
    =0jBP
    -----END PGP SIGNATURE-----
    Solbu, Jul 5, 2005
    #7
  8. Maik Wiege

    Solbu Guest

    -----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-----
    Solbu, Jul 5, 2005
    #8
  9. Maik Wiege

    Chris Salter Guest

    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.
    Chris Salter, Jul 5, 2005
    #9
  10. 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
    Michael Heiming, Jul 5, 2005
    #10
  11. >>>>> "MH" == Michael Heiming <> writes:

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

    But this does not usually happen. Just so we're talking about the same
    thing: "reverse DNS" means looking up a name from an address, via a PTR
    record. So, you're saying the browser looks up an address from the name
    the user types, then does a reverse lookup to get a name again, and checks
    that. Most browsers don't do this; they check the name in the URL,
    without canonicalization.

    Canonicalization would actually have advantages -- for one thing, it could
    prevent the spurious foo.com vs www.foo.com warning I mentioned earlier.
    And since we're already relying on the insecure DNS for the forward
    lookup, it could be argued that canonicalization introduces no new
    vulnerability, as the user really should check the certificate for every
    SSL connection -- the browser's check of the URL hostname against the
    certificate CN is really only advisory. Nonetheless, the fact remains
    that most browsers do not do what you describe.

    --
    Richard Silverman
    Richard E. Silverman, Jul 5, 2005
    #11
  12. "Richard E. Silverman" <> writes:
    > 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.


    the foo.com vis-a-vis www.foo.com was early problem ... and then they
    went to wildcard certificates and wildcard browser processing ... so
    that browser would get a *.foo.com ssl domain name certificate and it
    would accept for all URLs ending in foo.com.

    slightly related posting in sci.crypt
    http://www.garlic.com/~lynn/2005l.html#19

    what you typed in is matched against the site you are dealing with.

    the original major application was e-commerce
    http://www.garlic.com/~lynn/aadsm5.htm#asrn2
    http://www.garlic.com/~lynn/aadsm5.htm#asrn3

    the problem was that a lot of the e-commerse sites found that SSL
    reduced their capacity by 80-90 percent. as a result, most sites went
    to not invoking https/ssl until you hit the checkout/pay button.

    the vulnerability is that one of the SSL objectives was countermeasure
    against man-in-the-middle &/or impersonation attacks. if you happen to
    be dealing with a bogus site w/o SSL (because nobody uses SSL until
    the checkout/pay phase) ... and then you get to the checkout/pay
    button ... it is highly probable that any bogus site will supply a URL
    (which you haven't typed in) that corresponds to some valid SSL domain
    name certificate that they actually posses.

    there is actually a funny catch-22.

    one of the SSL justifications was as a countermeasure to perceived
    integrity problems in the domain name infrastructure.
    http://www.garlic.com/~lynn/subpubkey.html#sslcert

    however, when somebody applies for an SSL domain name server
    certificate, the certification authority must check with the
    authoritative agency for domain name ownership. this turns out to be
    the same domain name infrastructure that has the integrity issues
    giving rise to the requirement for SSL domain name certificates.

    basically the certification authority asks for a lot of identification
    information so that it can go through the complex, expensive and
    error-prone process of matching the applicants supplied identification
    information with the identification information on file for the
    domain name owner at the domain name infrastructure.

    so somewhat with the backing of the certification authority industry,
    there has been a proposal to improve the integrity of the domain name
    infrastructure by having domain name owners registering a public key
    with the domain name infrastructure. An objective is improving the
    integrity of the domain name infrastructure by having all
    communication from the domain name owner be digitally signed ... which
    the domain name infrastructure can authenticate with the on-file
    public key (having all communication authenticated, improves the
    integrity of the domain name infrastructure, which in turns improves
    the integrity of the checking done by the certification authorities).

    As an aside observtion ... this on-file public key
    results in a certificateless, digital signature operation.
    http://www.garlic.com/~lynn/subpubkey.html#certless

    The other issue for the certification authority industry, is that they
    can now require that SSL domain name certificate applications also be
    digitally signed. Then the certification authority can retrieve the
    on-file public key from the domain name infrastructure to authenticate
    the digital signature on the application. This also turns an
    expensive, complex, and error-prone identification process into a much
    less expensive, straight-forward and more reliable authentication
    process.

    The problem (for the CA industry) is that the real trust ruot for the
    SSL domain name certificates is the integrity of the ownership
    information on file with the domain name infrastructure. Improving
    this trust root, in support of certifying SSL domain name certificates
    .... also improves the overall integrity of the domain name
    infrastructure. This, in turns minimizes the original integrity
    concerns which gave rise to having SSL domain name certificates.

    The other problem (for the CA industry), if they can retrieve on-file
    trusted public keys from the domain name infrastructure, it is
    possible that everybody in the world could also retrieve on-file
    public keys from the domain name infrastructure. One could then
    imagine a variation on the SSL protocol ... where rather than using
    SSL domain name certificates (for obtaining a website's public key),
    the digital certificate was eliminated and the website's public key
    was retrieved directly.

    In fact, a highly optimized transaction might obtain the website
    ip-address piggybacked with the website public key in a single message
    exchange (eliminating much of the SSL protocol chatter gorp that goes
    on).

    In that sense, such an SSL implementation, using on-file public keys
    starts to look a lot more like SSH implementation that uses on-file
    public keys (eliminating the need for digital certificates, PKIs
    and certification authorities all together).

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
    Anne & Lynn Wheeler, Jul 5, 2005
    #12
  13. Maik Wiege

    Mike Amling Guest

    Michael Heiming wrote:
    > 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 <>

    >
    >
    >>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.


    SSL does not use reverse DNS (in case anyone was wondering).

    --Mike Amling
    Mike Amling, Jul 5, 2005
    #13
  14. "Richard E. Silverman" <> wrote in message
    news:...

    > 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.


    And 99% of people will simply click on and accept that SSL key after that
    warning, especially self-signed keys. The top-down chain of authoritty for
    accepting signed SSL keys is fairly broken in that sense.

    > 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.


    Also stealing it or abusing someone else's rootkitted server to steal the
    keys. Given the traffic in zombied machines for sending spam, I'd be quite
    surprised if there's not a healthy traffic in cheap SSL keys stolen from
    poorly secured companies computers, especially university sites.
    Nico Kadel-Garcia, Jul 6, 2005
    #14
  15. In article <>,
    Michael Heiming <> wrote:

    >Your browser will check the cert against reverse DNS and
    >bail out if these don't match, end of story.


    The check is done against forward DNS, not reverse.
    Lawrence D¹Oliveiro, Jul 18, 2005
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Nosey

    Mens Sterling Silver Chains?

    Nosey, May 28, 2005, in forum: Computer Support
    Replies:
    3
    Views:
    565
    Dave Lear
    May 29, 2005
  2. Allan
    Replies:
    1
    Views:
    433
  3. Replies:
    7
    Views:
    4,249
    Kimba W. Lion
    Jan 26, 2007
  4. Sigma2

    markov chains

    Sigma2, Nov 30, 2007, in forum: Digital Photography
    Replies:
    0
    Views:
    386
    Sigma2
    Nov 30, 2007
  5. MeekiMoo
    Replies:
    0
    Views:
    652
    MeekiMoo
    Jul 28, 2009
Loading...

Share This Page