Slashdot Mirror

And how does your browser know that http://www.yourbank.com/ which has a verisign issued certificate is your bank, and http://www.scambank.cn/ which also has a verisign issued certificate is not your real bank?

And therefore, how is the end user supposed to know that the binary signed by "Martin Pikryl" and verified by verisign is a genuine copy of WinSCP, and that the binary signed by "John Smith" and also verified by verisign isn't?

Sorry, try again. SSL is intended not just to secure the exchange of application-level bits, but also to validate that the destination site you entered is the one you reached. This is done by having the server present a certificate, which the client can then verify was signed by one of many trusted authorities.

Let's assume that browsers don't raise an alarm for untrusted certificates, as you propose. Let's further assume I can spoof ARP replies from your gateway, hijack your outbound connections to port 443, hijack your route to 1.2.3.0/24, or subvert your resolver functions for yourbank.com in any number of ways. Now, you go to https://yourbank.com/ and present your credentials. Guess what? I have them, and there's no warnings.

That is why SSL authenticates the remote site. Encrypting the transport prevents eavesdropping, while authenticating the remote site prevents man-in-the-middle attacks. You need both to have any degree of security.

Be thankful browser vendors have knowledgeable people to handle cryptography.

The problem is that Etisalat has a signing certificate which, in turn, is signed by Verizon. Evil, Inc. can get a certificate for a domain, say yourbank.com, and get Etisalat to sign it. When your browser goes to https://yourbank.com/ the owner of this certificate can do a man-in-the-middle attack and substitute their certificate for yours. Your browser will look at the certificate and see that it's signed by Etisalat. It will then fetch Etisalat's signing certificate and see that it's signed by Verizon. It trusts Verizon, so it will show you a happy 'this page is secure' icon. You happily give your online banking credentials to a random person, they take your money, and your bank says it's your fault because you provided the criminals with your online banking details.

It's not up to Etisalat to police the Internet, but it is up to them to police the certificates that they sign. Signing Etisalat's signing certificate means that they are saying publicly that they are willing to stake their reputation on the fact that any certificate signed by Etisalat can be trusted. The EFF is calling them out on this.

All I saw was https://login.yourbank.com/?login=********&password=********

otherwise the admin would easily see https://login.yourbank.com/?login=you&password=hunter2

This is, supposedly, what EV certificates provide

The real question is, then, can obtaining an EV cert also prevent RapidSSL from then issuing you another cert? Unless you've thoroughly trained your users to look for that green bar, they could still intercept https://yourbank.com/ using a brand-new RapidSSL cert for that same domain.

if you set up your fake server for hugebank.com, and have it serve up redirects to your newly registered (and certified!) hugebank.secure-banking.dom site, then the user will see a validated site that they got to by typing in their bank's address or following an email link.

There's no reason for a bank to send out a non-https link in an email. I am in the habit of typing https for several sites -- gmail being the main one.

And if it wasn't for the banks (including my current bank) which are Doing It Wrong (sending me to a third-party site for the actual banking), I would be very suspicious seeing anything other than hugebank.com in the URL, validated or not. In fact, the first time this happened, I called them and asked what was going on -- they confirmed that they outsource this stuff.

Our school uses a self-signed certificate for the courseware.

Than tell the admins to fix it. School environments are hard to do, because you have a lot of non-standard clients. So a public cert would probably be better for a school than an internal CA (which would make sense for a company).

Again: Firefox and IE both give a very stern warning that what you're going to do is potentially risky. This is the *RIGHT* thing to do - if that wasn't the case, with the recent DNS issues it would be easily possible to spoof https://www.yourbank.com./

Basically, don't blame Firefox if your cost-cutting measures break on you - it's your own fault.

Why don't you stop talking out of your fucking ass, and just read my post which makes clear how my system makes it totally easy for the user?

I said the trust servers, and vouchers for those servers, would ship with defaults. All a casual user would do would see whether a given page is trusted, as a function of those two layers they'd never see. More sophisticated users could set their "vouch servers", probably by their organizations tech support. Even more sophisticated users could pick their own trust servers. Or make their own trust servers, or their own vouch servers. An open system with defaults that "just work" for everyone, unless they're inclined to tinker. With a simple mechanism for delegating the decisions of who to trust.

My privacy scope keyed to trust, automating form completion, makes it even easier for the casual user to decide what to do (or not), once trust levels are established. It becomes a matter of seeing a page asking for info, and just saying "OK/"Cancel" when the browser just says "This page is asking for your creditcard info, but YOUR_FINANCE_MAGAZINE says you shouldn't trust it. Do you want to do it anyway, or get more info before you give it to them?" Also with open configs, so for casual users it "just works", but more support/sophistication can use others' input into the trust web.

Distributed trust is complex. My system, drawing on decades of people working out how people trust and what's easy to understand, makes it easy for the 99.9999% who want to trust, and blame the people who vouched when it goes wrong. While accommodating the few, including me, who understand how to tailor trust even better.

You are clearly part of the "six nines" who need it totally dumbed down, or you get scared into confusion. Just step away from the keyboard while pros do the hard work, and you'll get your simple, trustworthy interface. Getting in the way of the machinery can be dangerous for mere normals like you.