Likes Likes:  0
Resultaten 1 tot 2 van de 2
Geen
  1. #1
    \Hal Finney\
    Re: OpenID/Debian PRNG/DNS Cache poisoning advisory
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: OpenID/Debian PRNG/DNS Cache poisoning advisory

    [I feel a little uncomfortable replying with such a wide distribution!]

    Getting browsers, or OpenID installations, to check CRLs or use OCSP to
    check for freshness is likely to be slow going. At this point I think
    the momentum still favors fixing the remaining DNS systems that are
    vulnerable to cache poisoning. This turnkey-MITM bug makes OpenSSL bad
    certs far more exploitable, as Dan Kaminsky pointed out in his report.
    OpenID is just one example of many where this is going to keep happening
    as long as DNS is unpatched.

    I thought of one possible mitigation that can protect OpenID end users
    against remote web sites which have not patched their DNS. OpenID
    providers who used weak OpenSSL certs would have to change their URLs
    so that their old X.509 CA certs on their old URLs no longer work on the
    new ones. This will require all of their clients (users who log in with
    their OpenID credentials) to change their identifiers. DNS based MITMs
    will not be able to forge messages related to the new identifiers.

    Customers can be alerted to this requirement as soon as they log in to
    a web site (relying party) whose DNS is NOT hacked; the redirection to
    the OpenID provider will give opportunity to notify the customer of the
    name change. Making this change may be somewhat inconvenient, but since
    OpenID is a relatively new standard, at least it is easier than would
    be the case with a more established protocol.

    In the other direction of attack, the end user's DNS is poisoned and
    he gets redirected to a bogus site in place of the OpenID provider;
    that site is then able to provide a valid SSL certificate due to the
    OpenSSL weakness, thereby stealing whatever authentication credentials
    the user normally sends to his OpenID provider. This is one instance of
    the general attack where a user is DNS-misdirected to a bogus copy of
    a secure site which unfortunately used weak OpenSSL based certs.

    Again, I see fixing the DNS as the path of least resistance here,
    especially so since the end user is the one bearing most of the risk,
    typically DNS is provided by an ISP or some other agency with a formal
    legal relationship, and there is the possibility of liability on the
    part of the lax DNS provider. Hopefully we will continue to see rapid
    uptake of the DNS fix over the next few weeks.

    That still leaves weak-cert OpenID users vulnerable to DNS-unpatched
    service providers (OpenID relying parties), and that is where my proposed
    mitigation above comes in. By renaming its URLs, an OpenID provider who
    had the misfortune to create a weak OpenSSL cert (through no fault of
    its own) can save its end users considerable potential grief.

    Hal Finney


  2. #2
    Ben Laurie
    Re: OpenID/Debian PRNG/DNS Cache poisoning advisory
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: OpenID/Debian PRNG/DNS Cache poisoning advisory

    Hal Finney wrote:
    > I thought of one possible mitigation that can protect OpenID end users
    > against remote web sites which have not patched their DNS. OpenID
    > providers who used weak OpenSSL certs would have to change their URLs
    > so that their old X.509 CA certs on their old URLs no longer work on the
    > new ones. This will require all of their clients (users who log in with
    > their OpenID credentials) to change their identifiers. DNS based MITMs
    > will not be able to forge messages related to the new identifiers.


    Yeah, I considered this scheme. The problem is that it doesn't really
    help the relying parties, who can still be fooled into believing an
    existing user is returning (or a new one is arriving) from the original
    site. This is particularly a problem for Sun's OpenID Provider, which
    makes the additional assertion (out of band) that the user is a Sun
    employee. So, anyone can become a Sun employee, as of a few days ago.

    This is why the lack of CRL checking in OpenID libraries is an issue.

    > Again, I see fixing the DNS as the path of least resistance here,
    > especially so since the end user is the one bearing most of the risk,
    > typically DNS is provided by an ISP or some other agency with a formal
    > legal relationship, and there is the possibility of liability on the
    > part of the lax DNS provider. Hopefully we will continue to see rapid
    > uptake of the DNS fix over the next few weeks.


    In general, DNS is not fixable without deploying DNSSEC.

    a) The current "fix" just reduces the probability of an attack. If
    attacker and victim have sufficient bandwidth, it can still be done in
    under a day.

    b) There are many scenarios, mostly revolving around the use of wireless
    hotspots, where users are easily fooled into using a malicious DNS provider.

    So, DNS patching is not, IMO, the real answer to this problem. Of
    course, the second scenario has been around forever, but is conveniently
    ignored when explaining why CRLs are not necessary (and all other things
    that rely on perfect DNS). All that's happened recently is we've made
    people who are sitting still just as vulnerable as travellers.

    But increasingly we are all travellers some of the time, from a "how we
    get our 'net" POV. We really can't ignore this use case.

    Cheers,

    Ben.

    --
    http://www.apache-ssl.org/ben.html http://www.links.org/

    "There is no limit to what a man can do or how far he can go if he
    doesn't mind who gets the credit." - Robert Woodruff


Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2026 Webhostingtalk.nl.
Web Statistics