Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security Software

Browser Extension Defeats Internet Eavesdropping 194

Pickens writes to tell us that researchers at Carnegie Mellon University have created a simple system to help prevent man-in-the-middle attacks. Using a preset list of friendly sites called 'notaries,' the new 'Perspectives' system helps users to authenticate sites that require secure communications. Additionally this should help with the recently debated solution implemented by Firefox that has so many users frustrated and confused. "By independently querying the desired target site, the notaries can check whether each is receiving the same authentication information (a digital certificate), in response. If one or more notaries report authentication information that is different than that received by the browser or other notaries, a computer user would have reason to suspect that an attacker has compromised the connection."
This discussion has been archived. No new comments can be posted.

Browser Extension Defeats Internet Eavesdropping

Comments Filter:
  • Excellent!! (Score:2, Insightful)

    by shaitand ( 626655 )

    Now certs can finally be about the way they are actually used. Encryption. This should put an end to the argument that verifying encryption without verifying the identity of the third party allows man-in-middle attacks.

    • Re:Excellent!! (Score:5, Informative)

      by Anonymous Coward on Monday August 25, 2008 @02:05PM (#24739717)

      So, how exactly can you tell the difference between the third party and say, the man-in-the-middle?

      Since you claim to be able to do so without being able to verify the identity of the third party?

      Certificates were never about encryption. They were always about identity. As in I possess a unique item (a specific sequence of random digits, called a "private key") that I can use as a token and present at my discretion alone, to prove my participation in some activity without being physically present. In other words, the token is a proxy, and thus serves to identify the presenter.

      The fact that this "key" has some unique properties in that through some fancy math, I can prove that I can access and use this "key", but not have to disclose it to you is what makes it useful for other tasks, such as encryption and digital signatures.

      Self-signed certificates are useful only to indicate that you are having a conversation with an anonymous person, and NO assertions about the identity using the private key can be made.

      You are free, of course, to put an end to any argument requiring intelligence to participate due to your obvious lack thereof.

      The primary problem with certificates, IMHO, is the fact that within the certificate itself (or even the CSR for that matter), there are no assertions whatsoever as to the private key management and access controls in place.

      Therefore, I find it amusing that there are Certification Authorities that are willing to make assertions as to the authenticity of any entity possessing access to the private key of that certificate being, in fact, the entity represented in the meta-data surrounding the public key in the CSR/certificate.

      There is no way to know if a webserver is protecting its certificate private key at all (e.g. and serving it up as a normal document that anyone can request) without PBE (Password Based Encryption) in PKCS#8 PEM-encoded format, or whether the key was generated within a FIPS-140-2 Level 3 or higher device and cannot be exported outside of the security boundary/device.

      Without that knowledge, you cannot determine an informed level of trust with which to associate the identity represented by the certificate.

      Assertions of Identity require the attribute of uniqueness. I am underwhelmed at the lack of any framework or standards to define, measure, and assert probabilities that one's unique random sequence of digits (private key) is, in fact, unique.

      • Better yet, refer to this post.

        http://slashdot.org/comments.pl?sid=656323&cid=24739889 [slashdot.org]

      • The MITM argument does not differentiate between self signed (for encryption only) and CA-signed (for identity verification) use of certs. It is an illogical argument to say Certs are not useful for encryption due to MITM concerns, but certs are useful for establishing identity.

        If someone is at the root "In The Middle" point, between a client and the WAN, they can forge the Certificate Authority transaction to represent their cert as valid, claiming to be whoever they want.

        • Re: (Score:3, Informative)

          If someone is at the root "In The Middle" point, between a client and the WAN, they can forge the Certificate Authority transaction to represent their cert as valid, claiming to be whoever they want.

          There is no "Certificate Authority" transaction. The CA signature on the site certification is verified locally against a whitelist of CA public keys built into the web browser. The fact that anyone can create their own self-signed key for any domain is exactly why such keys do not establish identity, making MI

          • Thanks for the clarification. Wikipedia appears incorrect on this matter (http://en.wikipedia.org/wiki/Transport_Layer_Security#How_it_works), if you wanna fix it to be more clear.

            • It's not really incorrect. The client can optionally contact the CA for additional validation; this is typically done to determine if the certificate has been revoked since it was originally issued. The certificate itself still has to be signed by a trusted CA, as indicated by the second bullet point under the Security [wikipedia.org] section:

              The client verifies that the issuing CA is on its list of trusted CAs.

          • By contrast, CA-signed certificates can't be forged without first breaking (or otherwise acquiring) an established CA's signing key.

            Someone ought to tell Verisign that [llnl.gov].

            A CA-signed certificate guarantees that your data can only be decrypted by the intended recipient. There's no way to tell whether a self-signed certificate belongs to the intended recipient or a MITM, which renders the encryption useless against a determined attacker.

            No, they don't.

            It guarantees it using a very narrow definition of guarantee

            • Re: (Score:3, Insightful)

              I'm not trying to say that a CA-signed certificate is an absolute guarantee of identity. If you can actually trust the certification authority, and everyone follows all the rules and keeps their private keys secure, and the private keys aren't broken by brute force or cryptoanalysis, then the authentication will be valid. These conditions are implied in any security arrangement, and pointing out that they may not hold in any given implementation adds nothing useful to the discussion. Everyone is already qui

      • Re: (Score:3, Interesting)

        by camperdave ( 969942 )
        Self-signed certificates are useful only to indicate that you are having a conversation with an anonymous person, and NO assertions about the identity using the private key can be made.

        Can you not, with reasonable certainty, be confident that the anonymous person you're dealing with now is the same anonymous person who was using the key last month? After all, the exchange of keys is supposed to take place over a secure channel.
    • Re:Excellent!! (Score:5, Insightful)

      by kestasjk ( 933987 ) on Monday August 25, 2008 @02:12PM (#24739813) Homepage
      Problem is it doesn't work if the Man-in-the-middle is between both the "notary" trusted authority and the end-user client. (i.e. the MITM attack is done on the server-end)

      It does make the attacks less realistic to perform, to be sure, but it still doesn't provide the same assurances which signed certificates claim to. In a sense it's the same system, except the only check performed is that the "notary" (i.e. certificate authority) only does a fairly simple check.

      So; it'd be good, it'd improve things, but it wouldn't end the debate, and you can bet VeriSign would oppose it in any way they can.
      • Re: (Score:3, Informative)

        by kestasjk ( 933987 )
        Before anyone else comments on this, I'll clarify:

        Problem is it doesn't work if the Man-in-the-middle is between both the "notary" trusted authority and the end-user client. (i.e. the MITM attack is done on the server-end)

        The MITM attack would have to be in-place from the moment the self-signed cert is first used, because the "notaries" keep logs and would notice a change. Again; it makes an MITM attack much more unrealistic, and I'd definitely be in favor of this being using, but I don't think it'll close the debate.

        • Re:Excellent!! (Score:4, Insightful)

          by DragonWriter ( 970822 ) on Monday August 25, 2008 @04:22PM (#24741801)

          The MITM attack would have to be in-place from the moment the self-signed cert is first used, because the "notaries" keep logs and would notice a change.

          No, it would need to be in place before the moment that the self-signed cert is first reported to the notaries, if the functionality of reporting such mismatches were enabled, which it apparently is not by default at least now.

          But what do they do even if it has changed over time? After all, if the idea is to render authority-signed certs unnecessary, wouldn't you expect servers to abandon them as they expire, replacing them with self-signed certs? Is that going to be flagged as risky?

      • Re:Excellent!! (Score:5, Informative)

        by archatheist ( 316491 ) on Monday August 25, 2008 @02:19PM (#24739889)

        This is in the FAQ. From TFA:

        Q: But what if an attacker takes over all paths to the destination?

        A: There are two answers to that. Please see our academic paper for a detailed security analysis.

        1) Perspectives actually keeps a record of the keys used by a service over time. Thus, even if a powerful adversary is able to take over the whole Internet (scenario L_server in the paper), clients can still detect the key as suspicious because the key has recently changed. If the attacker is able to compromise all paths for a long time, then you are in trouble, but then again such a powerful adversary could also fool the so-called "verification procedures" of many certificate authorities, which often consist of a one-time email verification.

        2) Even though a powerful adversary can defeat the system, it makes man-in-the-middle attacks much harder. Today an attacker must only be on the path between you and the destination, which isn't very hard. Think about an open wireless network, or the recent DNS attacks which compromise a targeted DNS resolver. Being on all links is much harder, and in the end security is nothing but making an attack harder.

        • Q: But what if an attacker takes over all paths to the destination?

          A: Unless the attacker is the service providing your connection (This may not be your ISP; if you're using DSL it might be your telco, or a big DSL provider. If you're on dial-up, your ISP might be leasing the PoP from some other national or local company, such as UUNet.) such control is almost impossible, and at best, highly unlikely. There would have to be at least one choke point, or possibly a choice among a very small number of them

        • "clients can still detect the key as suspicious because the key has recently changed"

          That only works if the client has a copy of the proper certificate. If this is the first time the client is connecting to the "secure" server, a man-in-the middle attack that also intercepts communications along the path to the notary will succeed.

        • Q: But what if an attacker takes over all paths to the destination?

          You mean, like taking over the destination? Or their ISP? Or maybe their upstream?

          Seriously.

          It's not like that never happens.

      • Re: (Score:3, Interesting)

        by mccabem ( 44513 )

        I can see having multiple paths to your destination host (the server) will probably eliminate most MITM attacks under this system. However, our presumption of honesty is with the ISP's of course. If they decide to go "man in the middle" again (reaching a little for argument's sake) at the request of the government (or otherwise) are all bets still off? In other words, if all paths are considered to be compromised/under attack before the first use of the Notary system, can it still be considered effecti

    • Wrong. This may increase the difficulty of the MITM attack by some constant amount (the number of notary servers checked) but does not foreclose the possibility that the notary requests themselves might be intercepted and impersonated by the MITM so the attack remains theoretically viable. That is the problem with MITM, it has more lives than Schrödinger's cat [wikipedia.org]. Just when you thought that you had gotten rid of it it comes back in a revised form. The best solution thus far is and remains the inclusion of
      • 'but does not foreclose the possibility that the notary requests themselves might be intercepted and impersonated by the MITM so the attack remains theoretically viable.'

        No, it does not remove the theoretical possibility but it does remove the practical possibility.

        The other method fails in both theory and practice because the security relies on the assumption of trust and that is not a sound principle in theory and is definitely not been shown to be sound in practice.

  • unless the site was compromised and everyone started receiving the false certificate. Maybe they could also have a store of previous certs to compare it against?

    • Browsers already do store previous certs, and warn you if they change. This is for the initial query, I think.

    • Re: (Score:3, Informative)

      by Mierdaan ( 134219 ) *

      From the project's website:

      "Q: But what if an attacker takes over all paths to the destination? ...

      A: Perspectives actually keeps a record of the keys used by a service over time. "

      • A: Perspectives actually keeps a record of the keys used by a service over time. "

        Somehow I doubt this. Or I should say, I doubt this will be extensive or practical enough to be useful for the following reasons:

        1. How can keep a record of all the keys used by different services? I understand that storage is increasing, but there are potentially billions of websites. How are you going to keep track of all those keys?
        2. And continuing along that line, how do you keep track of those billions (or at the very least
    • Re: (Score:2, Informative)

      by Anonymous Coward

      ... Maybe they could also have a store of previous certs to compare it against?

      RTFA (I know, I must be new here...).

      They do.

  • by TorKlingberg ( 599697 ) on Monday August 25, 2008 @01:33PM (#24739273)
    Interesting idea, but it will not work if the man-in-the-middle is hijacking the websites connection rather than the users.
    • by angio ( 33504 ) on Monday August 25, 2008 @01:40PM (#24739405) Homepage

      Halfway correct. The Perspectives user can also specify a time period over which the certs must be consistently observed (we don't default to using that right now, because it makes new websites not appear). Using this setting, Perspectives can help avoid short-lived attacks against the connection to the webserver.

      The motto behind this is roughly "You can fool all of the browsers some of the time, and some of the browsers all of the time..." - but an adversary who can hijack all connections to a site for a long period of time will defeat Perspectives.

          -Dave (one of the researchers on the project)

      • Re: (Score:3, Insightful)

        by spotter ( 5662 )

        this is probably a stupid question.

        Making a (possibly incorrect) assumption
        ---
        In general, a MITM attack is either going to attack a user or a site. Namely, I'm going to interpose between the site and all users, or between a user and all sites.
        ---
        In the former, if the attacker gets there early enough, how does the notary help? Especially as most sites where this would be in play are only single homed.

        In the latter, doesn't this just add an additional burden to MITM attacking the notaries (i.e. intercept th

        • by angio ( 33504 )

          It only helps for a short period of time - say, a day or two. If the attack against the whole site is successful for longer than that, Perspectives will eventually say "okay, that key's been around long enough, it's good." The assumption is that sites will eventually notice the attack -- which may or may not hold. :-) One cool thing about Perspectives is that you can use it to monitor your own site... if Perspectives starts showing a different key than the one you're using, you know you have a problem.

          • If a site legitimately has their key compromised (or they just for some reason need or want to change their key), how do they change it to something new and secure without that appearing to be a mitm until it's been there long enough that Perspectives accepts it?

    • by Tom ( 822 )

      One: See angio/Dave's reply.

      Two: Hijacking the website in, or all connections from a datacenter is usually a lot more difficult and expensive than going down to your local cable/DSL/whatever hub and playing maintainance crew, or taking over your WLAN router (or the one in the hotel you're staying in).

      Case in point: Not very many banks are robbed anymore the old-fashioned way. But there's a lot more going on with ATM machines than the banks let us know.

    • It'll also fail if mitm is hijacking the server.

  • I thought the whole point was to have an "authority" (like verisign etc) sign your certificate. So MitM can't just swap in their own cert because to change it would break the signature?

    Or are they just shooting for a free alternative? signed SSL certs are more expensive than some smaller places want to bother with.

    • They accomplish different things. A true cert tells you that when you're talking to xyzcorp.com that you're really talking to XYZ Corp. of Bumfuck, IA and that this information was verified within the last year. This notary system would simply tell you that the xyzcorp.com you're talking to is the "real" xyzcorp.com, and not some spoofed version. For example, this technique would work for an anonymously run site, but a normal SSL cert would not allow that.

      Of course the fact that you don't have to cough up m

    • I thought the whole point was to have an "authority" (like verisign etc) sign your certificate. So MitM can't just swap in their own cert because to change it would break the signature?

      Unless the MITM can get his cert signed as well. Do you know all the authorities that your browser trusts by default? There are many others besides verisign.

    • by TopSpin ( 753 ) *

      Or are they just shooting for a free alternative?

      The "just" part there is considered a problem. The argument goes that SSL would be ubiquitous if there were no cost, hassle, discloser requirements, etc. Imagine, for instance, that common web servers automatically generated self-signed certs as needed and that these certs were used to encrypt everything by default. This is how SSH servers (OpenSSL) typically work today.

      As it is this isn't really possible because browsers erupt warnings, confirmation dialogs and other spasms when a self-signed cert is en

      • $15 and a phone call to get a signed cert really is too much to ask. Some people have a difficult time understanding that.

        How to fix it? I dunno.

        Actually it's very simple: have every domain name come with a certificate, signed by the domain provider (chaining all the way up to the root name servers) and good for signing any subdomain/machine in the domain. Problem solved.

        But of course if you do that, then Verisign is going to go "WAAA ! We're losing profits !", so it won't happen.

  • by querist ( 97166 ) on Monday August 25, 2008 @01:38PM (#24739375) Homepage

    The idea of "notaries" is essentially the same idea as having the Certificate Authorities: a third party who is considered trustworth and sufficiently dilligent that the third party would take the appropriate measures to verify something before signing off on it.

    Who picks these people/companies?

    Why not use a system like PGP, building a web of trust?

    Disclaimer: I am a SC Notary Public.

    • by ccguy ( 1116865 ) * on Monday August 25, 2008 @01:54PM (#24739559) Homepage

      The idea of "notaries" is essentially the same idea as having the Certificate Authorities: a third party who is considered trustworth and sufficiently dilligent that the third party would take the appropriate measures to verify something before signing off on it.

      No it's not. These notaries don't sign anything and don't guarantee anything.

      They just tell you what they see (which is useful because it's unlikely than a man-in-the-middle between the client and the site is also between the notary and the site), and what the saw before (so you can check certificates that the site used before you first visited it).

      Who picks these people/companies?

      Probably not important, because you check 3 or 4 (out of thousands) notaries around the world before deciding whether a certificate looks OK or not. So it's not easy to setup a "bad notary" that actually works.

      I think this a promising idea.

      • No it's not. These notaries don't sign anything and don't guarantee anything.

        I think it is the same thing.
        The notaries are simply 'certificate authority - lite'.

        They are providing exactly the same service (a level of identity trust) as CAs. The mechanics are different, no signing certs, but the role is the same.

        • by ccguy ( 1116865 ) *

          They are providing exactly the same service (a level of identity trust) as CAs. The mechanics are different, no signing certs, but the role is the same.

          OK, so you go to the DMV or wherever IDs are issued in your country and get one. Then you show it to someone in the street and ask for a description of that ID.

          Do the DMV and the guy in the street have the same role? One is issuing the ID (and making sure they give it to the right person) and the other is just looking at an ID someone else issued. The

      • Not easy to set up a bad notary that works for spoofing a site, but very easy to set up a bad notary that works for a DoS attack.

    • by Tom ( 822 ) on Monday August 25, 2008 @01:54PM (#24739569) Homepage Journal

      I think the point is that a large-enough number of candidates plus a random selection equals statistical trust - the larger the base, the less likely it is that there isn't at least one uncompromised notary in your random sample.
      A CA will always have the single-point-of-failure problem. While infiltrating Thawte certainly isn't something your average chinese hacker kid can do, it is certainly within the abilities of the NSA, or the KGB. The "web of trust" approach and the "we pick someone at random from a large crowd" approach both make it prohibitively expensive to compromise the sources of trust.

      If you pick 5 sources at random, even from a crowd where 50% have been compromised, you still have a 1-(0.5^5) ~= 97% chance of having at least one uncompromised trust source. That's a pretty good record against an enemy who could compromise half of what could be millions of candidates.

      • Bruce Schneier once chatted with the president of Verisign about how much it would cost to compromise Verisign's root signing key.

        They figured that organized crime could swing a leveraged buyout for USD15 million.

        (Any errors in the above are my fault).

        • I figure organized crime can do it for a lot less. Guido and Nunzio can do a lot of "leveraging" for a mere hundred thousand.
      • Great odds, but doesn't that provide an attacker with a way to break the system? With enough notaries giving false warnings on purpose, a random pick of 5 will very oftet tell you not to trust a site regardless of its actual status. Or am I missing a way to eliminate the problem of false positives here (disregarding normal certificate updates).
    • Re: (Score:2, Interesting)

      by Anonymous Coward

      The idea of "notaries" is essentially the same idea as having the Certificate Authorities

      Nope.

      By having several "Notaries" you can ask verification of you do not need to put all your trust in a single party: Ask multiple Notaries and only accept if all return the same info.

      If you want to include the possibility that one of those notaries goes bad (wonky connection, hijacked or simply not doing its job) than accept the info if the majority agrees on it.

      Personally I think a method like this (which spreads th

    • Re: (Score:2, Interesting)

      by redbu11 ( 1343351 )
      Trust isn't the key problem with CAs.
      The key issue is that CAs like Thawte or Verisign do not scale. They manually verify each certificate request, a very expensive and labor-intensive process. A customer ordering an SSL certificate for https://www.acme.com/ [acme.com] must provide CA with legal documents showing that (a) ACME corp actually exists, (b) he really works for ACME, (c) he is authorized to request the certificate, and so on..
      All submitted documents are manually verified by the CA (at least in theory).
    • by skeeto ( 1138903 )

      "But who trusts the trustmen?"

      Err... nevermind.

  • by Animats ( 122034 ) on Monday August 25, 2008 @01:44PM (#24739447) Homepage

    If you have a central trusted key server, there's no problem, and you don't need this. The whole point of public-key encryption is to eliminate the need for a central key server. How vulnerable is this new thing in a world with a large number of phony "notary" sites?

    People used to talk about voting-based "web of trust" approaches, but that stopped working when the bad guys got zombie farms.

  • by keithadler ( 562733 ) * on Monday August 25, 2008 @01:49PM (#24739511)
    1. Bringing down notaries would bring down all SSL/TLS traffic 2. Compromising the extension itself could allow for proxying of SSL traffic; exposing private information 3. Using the the notaries increases the footprint of SSL traffic; increasing the attack surface
  • band aids (Score:4, Interesting)

    by jacquesm ( 154384 ) <(moc.ww) (ta) (j)> on Monday August 25, 2008 @01:54PM (#24739563) Homepage

    This will have some effect, but it really is a band aid. If the certificate authorities would be doing their jobs and browsers would be more strict about using 'bad' certificates then this problem would not exist in the first place.

    The greed of the certificate issuers is what has devalued the security.

    Multiple layers of such security are not the same as a real solution.

    • Re: (Score:2, Interesting)

      by Atriqus ( 826899 )
      I have to agree about CA greed. Whenever I see a site using a Mozilla approved CA, my initial thought is no longer whether my connection is secure, but rather an acknowledgment that the site paid protection to Verisign that year.
    • This will have some effect, but it really is a band aid. If the certificate authorities would be doing their jobs and browsers would be more strict about using 'bad' certificates then this problem would not exist in the first place.

      You didn't RTFA. This plugin doesn't address certificates that have been erroneously issued at all. If the site presents a cert that validates back to a trusted root CA, is current, and contains the URL of the site that sent it, then Perspectives won't check anything.

      Perspectives addresses a different issue: sites that use self-signed or expired certs. While you can certainly argue that the owners of those sites should get proper certs, for many of them it just doesn't make sense.

      For example, I run

  • Easy DoS Attack (Score:5, Interesting)

    by plsuh ( 129598 ) <plsuh@g[ ]east.com ['ood' in gap]> on Monday August 25, 2008 @02:07PM (#24739737) Homepage

    Folks,

    Nice try, but this scheme is a bad idea. It opens up a really easy DoS attack. All the attacker has to do is present a bogus certificate or SSH host key to a quorum of the notaries. BAM -- the server is now blocked. In fact, if the attacker can do this over a sustained period, he can masquerade as the actual server.

    There's a reason why PKI works the way it does. There's a reason why you should use certificates or key pairs for authentication. The proposed system doesn't really help. Given that you can get a real SSL certificate for $15/year these days, only laziness leads to the use of a self-signed certificate.

    I read the darn paper (yeah, yeah, I know, this is Slashdot, I'm not supposed to do that). They have a DoS column in their table in the Security Analysis section but don't discuss DoS in the text at all. Notaries need to be well known and are thus obvious candidates for a DNS-based attack. Next!

    --Paul

    • This has been beaten to death so many fucking times it's unreal. $15 per wireless router is too much. $15 per every computer that could serve out a web page is too much. Encryption should be default and obstacles to using it should be lowered so that no one has to ever use http. If ssh required some authority to sign every computer out there, we would still be using telnet.

  • Yeah yeah yeah, there's a new thing that'll protect you 100% from hacks and then the next article is there's a new thing that can bypass all security protections and you're 100% likely to get hacked. If they're gonna keep running these stories, they might as well make them real:
    "New anti-hacking methods developed. You drive to the web host's datacenter and sit down at the server that contains the site you want and open the HTML files from there"
    • "New anti-hacking methods developed. You drive to the web host's datacenter and sit down at the server that contains the site you want and open the HTML files from there"

      But what if the attacker changes the roadsigns on the way, so that you end up at his MitM datacenter instead ?

  • I thought of something recently, which I'm not sure if it is a tremendously stupid idea, or has some merit, and I've been wondering - why couldn't DNS possibly be used as an additional way to verify SSL? Here's what I mean - right now, when you connect to a given server, you use DNS to lookup the server's IP, then connect to the server, which sends you back a certificate with the public key of the server. Unfortunately, you have no way to verify that the public key you are purportedly

  • by rew ( 6140 ) <r.e.wolff@BitWizard.nl> on Monday August 25, 2008 @02:28PM (#24740049) Homepage

    Certificates from trusted parties should be used to certify that the certificate signed to belong to www.yourbank.com actually does belong to yourbank.

    When certificate authorities break down, and issue www.yourbank.com certificates to somecrook, things break down.

    The master certificate of the certificate authority that issues such bad nonsense should be revoked ASAP, and things can go on as designed.

    • by cdrguru ( 88047 )

      The problem isn't that www.yourbank.com is compromised. Nor is it an immediate problem that www.somecrook.com is issued a certificate for www.yourbank.com.

      The problem is far closer to www.yourbanking.com being (a) allowed to exist and (b) issued a certificate for www.yourbanking.com saying all is legitimate. Everyone should know that if the two are held up against each other that www.yourbanking.com is a scam. Today, GoDaddy, Register.com and others will happily register the domain for you. I don't see

  • If one or more notaries report authentication information that is different than that received by the browser or other notaries, a computer user would have reason to suspect that an attacker has compromised the connection."

    This helps against some MitM attacks, but not against outright false-flag scams. Also, it provides limited help against MitM attacks where the "middle" is close enough to the other end that it is between all the notaries and the site to be verified. (Though monitoring certificates receive

  • Just an extra hoop? (Score:3, Interesting)

    by k1e0x ( 1040314 ) on Monday August 25, 2008 @02:33PM (#24740125) Homepage

    But in a MitM attack.. If the DNS can be intercepted and rerouted to a spoofed site.. or the cert can be intercepted on the fly and regenerated.. why can't the information sent back from the notary also be forged?

    Seems like an extra hoop for hackers to jump through but not an impossible one.

    • If I were designing it, the extension would have hard-coded into it a certificate that'd be used to sign all the notary SSL certificates. If a notary didn't present an SSL certificate signed by the hard-coded known certificate, it'd be rejected and considered immediate proof of an MitM attack.

    • Re: (Score:3, Funny)

      by zippthorne ( 748122 )

      Easy: Just have the notaries register with Verisign.

  • So... to defeat a Man-in-the-Middle attack, you use another Man-in-the-Middle that you can trust?

  • I got your MITM attack right here [youtube.com]! [youtube.com]

  • It seems that the MITM can accomplish his deception if he is sufficiently close to either the server or the client. If he's next to either of them, he can replace all the data going in or all the data going out, so that all I/O seems to be the same.

    In other words, your officemate decides to bridge your network connection through his computer without you realizing he's switched your cables. It doesn't really matter what the notaries say, because he can manipulate all of them to say the same thing, sin
  • by Valdrax ( 32670 ) on Monday August 25, 2008 @04:10PM (#24741577)

    So, the way to defeat internet eavesdropping is to have a centralized service that double-checks all the websites you go to?

    Does anyone else think this is mutually incompatible with any concept of anonymity online? In other words, this reduces the risk of one form of eavesdropping by having you accept an entirely different form of eavesdropping.

HOLY MACRO!

Working...