X.509 weakness? - SSH

This is a discussion on X.509 weakness? - SSH ; When I connect to a server using ssh the first time, I get a message asking if I really want to connect to this guy. I replace a server and recycle its IP address, ssh does not want me connect ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: X.509 weakness?

  1. X.509 weakness?


    When I connect to a server using ssh the first time, I get a message
    asking
    if I really want to connect to this guy.

    I replace a server and recycle its IP address, ssh does not want me
    connect as the certificate has changed.

    So is this a weakness? Say I connect to a server, accept its
    certificate and am happy.
    Bad guy Garth also snags a copy of the certificate.

    The next time I connect to the server, bad guy Garth has changed my
    DNS so that
    instead of going to the correct server, I go to bad guy Garth's server
    who is pretending
    to be my server. I look at the CN=www.freesoft.org and say, wow
    thats the
    server I want and the certificate is good. I am happy.

    Am I missing something? Is it possible, by manipulating a DNS server
    for a bad
    guy to server up a good certificate and have it be undetected by a
    client?

    -Mike


  2. Re: X.509 weakness?

    bsd_mike writes:
    > Am I missing something? Is it possible, by manipulating a DNS server
    > for a bad guy to server up a good certificate and have it be
    > undetected by a client?


    SSL tends to have other sorts of (possibly process) weaknesses.

    some old posts about being called into work work with this small
    client/server startup that wanted to do payments on their server
    http://www.garlic.com/~lynn/subnetwork.html#payment

    and they had this technology they called SSL ... and needed
    to work out and validate all the business processes
    http://www.garlic.com/~lynn/subpubkey.html#sslcert

    the original design point was that the person typed in the URL ... and
    then the server provided a ssl domain name certificate that the browser
    compared the domain name in the certificate against the domain name in
    the typed in URL. This allowed that the server that the person thot they
    were talking to was the server that they were talking to ... aka the
    person knew the connection between the server they wanted to talk to and
    the server's URL ... the browser/SSL part provided the connection
    between the URL and the server.

    However, relatively early, merchants found that SSL degraded their
    webserver thruput by something like 90% ... so SSL was quickly
    restricted to just the check-out/payment portion. Now, the user goes to
    a website (that isn't validated with SSL) and eventually clicks on a
    button that generates a URL for a payment website ... which is
    cross-checked against some SSL certificate. Since a potential attacker
    now may be providing both the URL and the certificates ... and the user
    has lost all association between the website they think they are talking
    and the corresponding URL ... the SSL check no longer means a whole lot
    (for just about all uses of SSL in the world today). This is the basis
    of a lot of phishing and other kinds of attacks ... providing a field
    for the user to click on ... that may claim one thing ... but the actual
    URL can be totally unrelated to what is being claimed. Then the SSL
    operation is only checking that the URL (possibly provided by an
    attacker) matches the certificate (also provided by the attacker).

    So, at least part of the original motivation for SSL was countermeasure
    to some perceived weakenesses in the domain name infrastructure.
    However, most certification authorities (that issue SSL digital
    certificates) aren't the authoritative agency for the information they
    are certifying. The authoritative agency is the domain name
    infrastructure. A certification authority asks for a whole bunch of
    identification as part of the application. Then an attempt is made to do
    the expensive, error-prone, and time-consuming operation of matching the
    supplied identification information with the identification information
    on file with the domain name infrastructure (as to the owner of the
    domain name).

    So, somewhat backed by the certification authority industry ... there
    are some activities to improve the integrity of the domain name
    infrastructure. However, this represents a catch-22 for the industry
    http://www.garlic.com/~lynn/subpubkey.html#catch22

    improving the integrity of the domain name infrastructure weakens the
    original justification for having ssl domain name certificates.

    Another catch-22 is some of the improvements in integrity involve
    domain name owners putting public keys on file with the domain
    name infrastructure ... then all future communication is digitally
    signed ... and then there is a (certificateless) verification of
    the digital signature with the onfile public key
    http://www.garlic.com/~lynn/subpubkey.html#certless

    The issue here is that the certification authorities then could also
    start requiring SSL digital certificate applications also be digitally
    signed. Then they could switch from an expensive, time-consuming,
    error-prone identification process to a much more reliable, simpler, and
    less-expensive authentication process ... by doing real-time retrieval
    of the onfile public key to do a (certificateless) verification of the
    applicants digital signature.

    The further catch-22 is that if the certification authorities could
    start doing real-time (certificateless) public key operations ... then
    possibly the rest of the world would also start doing real-time
    certificateless public key operations also (eliminating all requirement
    for having the redundant and superfluous ssl digital certificate).

    One might even managed a super optimized, highly efficient variation,
    where the appropriate public key was piggy-backed on standard DNS
    response (in a single operation, possibly along with some crypto
    options). The client then generates a session key, encrypts the initial
    transmission, and then encrypts the session key with the servers public
    key. Then the stuff is sent in one transmission to the server. Only the
    correct server would be able to decrypt the session key. However, except
    for possibly small increase in payload size ... all the additional
    crypto-specific protocol chatter and transmission overhead has been
    eliminated.

  3. Re: X.509 weakness?

    >>>>> "bsd" == bsd mike writes:

    bsd> When I connect to a server using ssh the first time, I get a
    bsd> message asking if I really want to connect to this guy.

    bsd> I replace a server and recycle its IP address, ssh does not want
    bsd> me connect as the certificate has changed.

    bsd> So is this a weakness? Say I connect to a server, accept its
    bsd> certificate and am happy. Bad guy Garth also snags a copy of the
    bsd> certificate.

    bsd> The next time I connect to the server, bad guy Garth has changed
    bsd> my DNS so that instead of going to the correct server, I go to
    bsd> bad guy Garth's server who is pretending to be my server. I look
    bsd> at the CN=www.freesoft.org and say, wow thats the server I want
    bsd> and the certificate is good. I am happy.

    If you're actually using X.509 certificates, the idea is that this should
    not happen. You will only say the certificate is "good" if it's signed by
    a CA that you trust, and such a CA should not issue a certificate for
    www.freesoft.org to anyone but the legitimate owner of that domain.

    Note that although there are SSH implementations which use certificates,
    you're probably not using one. If you're using stock OpenSSH, there are
    no X.509 certificates, just public keys bound to names in your known_hosts
    file. In this case, *you* are responsible for verifying the name/key
    association on the first connection (e.g. by obtaining the fingerprint
    from a trusted source).

    bsd> Am I missing something? Is it possible, by manipulating a DNS
    bsd> server for a bad guy to server up a good certificate and have it
    bsd> be undetected by a client?

    bsd> -Mike


    --
    Richard Silverman
    res@qoxp.net


  4. Re: X.509 weakness?

    In article "Richard E. Silverman"
    writes:
    >>>>>> "bsd" == bsd mike writes:

    >
    > bsd> When I connect to a server using ssh the first time, I get a
    > bsd> message asking if I really want to connect to this guy.
    >
    > bsd> I replace a server and recycle its IP address, ssh does not want
    > bsd> me connect as the certificate has changed.
    >
    > bsd> So is this a weakness? Say I connect to a server, accept its
    > bsd> certificate and am happy. Bad guy Garth also snags a copy of the
    > bsd> certificate.
    >
    > bsd> The next time I connect to the server, bad guy Garth has changed
    > bsd> my DNS so that instead of going to the correct server, I go to
    > bsd> bad guy Garth's server who is pretending to be my server. I look
    > bsd> at the CN=www.freesoft.org and say, wow thats the server I want
    > bsd> and the certificate is good. I am happy.
    >
    >If you're actually using X.509 certificates, the idea is that this should
    >not happen. You will only say the certificate is "good" if it's signed by
    >a CA that you trust, and such a CA should not issue a certificate for
    >www.freesoft.org to anyone but the legitimate owner of that domain.
    >
    >Note that although there are SSH implementations which use certificates,
    >you're probably not using one. If you're using stock OpenSSH, there are
    >no X.509 certificates, just public keys bound to names in your known_hosts
    >file. In this case, *you* are responsible for verifying the name/key
    >association on the first connection (e.g. by obtaining the fingerprint
    >from a trusted source).


    All true (of course), but I think you missed the "snags" part. To the
    OP: The bad guy can snag certificates and SSH public keys all he wants,
    that's part of their being "public" after all, but that doesn't allow
    him to pretend to be anyone. In both cases the proof of identity lies
    with the possession of the *private key*, which can't be snagged by
    other means than breaking into the real server with the privileges
    needed to get at the key, if the owner is taking proper care of it.
    During authentication, the server is required to demonstrate that he has
    the private key that corresponds to the public one, and a bad guy that
    doesn't have the private key will not be able to do that.

    --Per Hedeland
    per@hedeland.org

+ Reply to Thread