Sounds pretty uncommon to me. What scenarios can you describe where an attacker is able to snoop but not hijack?
- Any time they don't catch the beginning of the session, since SSL doesn't allow swapping certificates mid-session.
- 99.9% of script kiddies sniffing wireless networks have sniffers but aren't set up to hijack.
Sure, that second point isn't worth much in theoretical security - but unauthenticated encryption would sure put the damper on the "wireless-dump.sh | grep '[1-9]{16}'" attack - which seems like a threat worth protecting against in practice.
Harder does not equal more secure, just more work for the attacker. Once he has your credit card details, you do not really care how hard it was to get.
Different attackers have the capability of executing different attacks. In security, attackers who can snoop and attackers who can hijack are considered to be sufficiently different that they're even given different names in the literature. Being able to defend against Eve is useful even if the defense doesn't help you against Mallory.
If we want to ignore the the capability of executing different attacks then nothing is secure. Everyone can execute the social engineering attack necessary to get access to every root CA certificate for example.
It's more like you're saying that it should be impossible to get a door without a lock. It gets cold in the winter, I'd like a door. I'd like to be able to have some privacy in my bedroom, I need a door. Sure... that's less secure than having locks on those doors, but saying I shouldn't have the choice is absurd.
First, if the attacker controls DNS he can probably succeed without any self signed certificate. All he needs to do is intercept the connection to the insecure bank home page and replace the log-in form with one that posts to http s://bank.com-------fakesite.com/ which he has a valid certificate for.
Second, the browser can warn about these certificate swapping attack by simply warning on every certificate change. This will help protect against MITM attacks for both recognized and unrecognized certificates as long as a user's first connection to a given site is hijacked (which isn't perfect, but it's a security improvement).
Remedial computer security lesson: The SSL protocal provides authentication and encryption. At the start of an SSL session the certificate is checked to authenticate the server and symmetric encryption keys are exchanged to encrypt the rest of the session.
In the article, I suggest that a site with a self signed certificate should be displayed with a white address bar, no lock, and a "this site cannot be authenticated..." info bar. How does that lead the user to a false sense of security?
If you're on a wireless link, those guys who can so easily snoop your traffic can also hijack your connections and launch MITM attacks.
This is true in theory and completely false in practice. Everyone and their dog has a wireless sniffer app. Hijacking a wireless connection is much more difficult.
Further, it wouldn't be too hard to provide practical warnings to the user in this case - if you store the certificate the first time you go to the site, you can flip out if it unexpectedly changes later.
Sure, a MITM attack trumps unauthenticated certificates. A phishing with similar URL attack or a trick-the-CA attack trumps an authenticated certificate.
A self-signed certificate is better than no certificate because it keeps out an attacker who can snoop but not hijack the connection. This is a common scenario, and worth protecting against.
Why should self-signed certificates be treated any worse than no certificate?
So far, I've heard about exactly one scenario where the current behavior would be better than simply treating a self-signed certificate like no certificate - if the attacker controls the user's DNS and the user is visiting a bookmarked https URL.
If an attacker controls your DNS, you've mostly lost already. If you don't have a bookmark to an https URL, the attacker can just point the form at another secure URL (with a valid certificate) or an insecure URL with the URL you expect.
Note that in the latter case (insecure but valid URL) the UI will look exactly the same as it would if Mozilla treated self-signed certificates like insecure sites.
Just getting users to accept self-signed server certificates is very bad, because it trains them to accept them, and they'll get phished.
How are they any more likely to get phished on a self-signed certificate than a valid certificate on the wrong URL or on the correct insecure (http) URL?
Self-signed certificates with unknown parties are pretty much tantamount to no security at all; the encryption can't be relied on for more than obfuscation. Probably the only good use for self-signed certificates is when you can get the certificate via a secure channel (and no, accepting the certificate via a browser dialog isn't a secure channel). Obviously, this approach doesn't scale.
Snooping a connection is a hell of a lot easier and more common than hijacking one. Hell, if someone can arbitrarily hijack connections, they can get themselves a completely valid SSL certificate by demonstrating their (hijacked) control of the domain to some minor CA.
There are no perfect answers to these security problems. But there are wrong answers - and requiring website owners to always sign up and be approved before they can use the HTTPS protocal on a public website is a wrong answer.
Ok, sure you can't even be sure unless you have the microcode running your hardware. But for 99.999% of people, the source is good enough.
Even then you can't be sure, because the hole could be built into the hardware. The best you can really do is get a stack of identical processors and chip sets and destructively slice all but one of them up and run them through an electron microscope to verify the circuits - but even then you'd only have a statistical guarantee and you still might miss some clever analogue circuitry trick.
To a first approximation, kidnapping child molesters don't exist. To a second approximation, every single person who might kidnap your child is a friend or family member - you and your child trust them, they won't need a net.
Remember: News is "something that almost never happens". Otherwise it wouldn't be news. If you see it on TV, you don't need to worry about it.
OK. Now that we're clear on where you stand, I can clearly present a conflicting view.
First, men and women really do learn differently. This isn't simply an issue of who gets more attention; the way the material is presented can make it easier for boys and hard for girls or vice-versa.
Second, this isn't "doing it wrong". The goal is to teach the students - if there is a way to present the material that makes it easy for girls it is best if girls are taught that way. Boys in the class are going to have a hard time, but it's better that some have an amazingly informative class than that everyone gets a mediocre class.
Personally, I think the best solution would be to test each student for learning style and then put them in a class with a teacher comfortable teaching in that style. My guess is that this will be very close to splitting by gender - but even if I'm wrong and boys and girls have identically functioning brains, this would still drastically improve education for everyone.
More attention was paid to boys, and they did better.
Now more attention is paid to girls (and material is taught in style that favors girls), and they do better in almost every area. The exceptions were mathematics, engineering, computing, and hard sciences.
If it's good that teaching-style change has made girls completely catch up in mathematics, then obviously you support a change in teaching style that will make boys catch up in biology and psychology - even if that makes it harder for girls - right?
Right. And obviously we want to be exchanging pieces of paper and database entries rather than lumps of metal. The question at hand is simply if money should be abstracting (backed by) physical assets like gold or iron or not.
The people with opinions on this topic seem to fall into three categories:
- Anti-statists, who think that governments can't be trusted with the power to create money out of thin air.
- Statists, who think that the idea of limiting governmental power is foolish.
- "Agents of inertia", who assume that there must have been a good reason to change off the gold standard and that anyone who is suggesting a change of direction is dumb and wrong.
That still leaves us without the basic information on what the *economic* benefits and disadvantages are of the two options and if there are other options that might be better than both.
There is nothing in mozilla's policy that requires any entity providing certs to charge a certain price.
No, but the effect of Mozilla's policy - for no actual user benefit - is to mandate that anyone who wants encryption must buy a certificate (from a specific list of vendors). And no, "but someone could offer certificates for free if they wanted to go through the audit process" is not an interesting argument.
Basically, the word means little more than "bad" these days.
The fact that some people are confused about the meaning of a term doesn't mean that it has somehow lost its meaning.
That seems like a somewhat shallow definition.
Yes, a bit. The literal definition of "proprietary" is simply "having to do with property". As jargon in the software field, it means "controlled by a single entity".
That's begging the question. I'm discussing what Mozilla's policy *should be*, and you're talking about the economics given a certain policy. Mozilla should act in the best interest of their users, not to maintain an high monetary price on encrypted browser sessions.
Every site on the web that would be worth encrypting traffic to is a business?
Every site can budget either $10/host name or $300/domain (for a wildcard cert)?
Even if they can, they should be expected to pay those prices if the authentication service that the CA provides is completely irrelevant to their threat model?
None of those assumptions are true.
There is a good argument for tying the lock icon to certificates issued by major commercial certificate authorizes, but tying the actual encryption to it can only make the internet less secure.
Slashdot Mirror
A VM, curly brackets, static typing, one-module-hierarchy library namespace, OO-is-primary paradigm. Yea... it's a Java clone.
- Any time they don't catch the beginning of the session, since SSL doesn't allow swapping certificates mid-session.
- 99.9% of script kiddies sniffing wireless networks have sniffers but aren't set up to hijack.
Sure, that second point isn't worth much in theoretical security - but unauthenticated encryption would sure put the damper on the "wireless-dump.sh | grep '[1-9]{16}'" attack - which seems like a threat worth protecting against in practice.
Different attackers have the capability of executing different attacks. In security, attackers who can snoop and attackers who can hijack are considered to be sufficiently different that they're even given different names in the literature. Being able to defend against Eve is useful even if the defense doesn't help you against Mallory.
If we want to ignore the the capability of executing different attacks then nothing is secure. Everyone can execute the social engineering attack necessary to get access to every root CA certificate for example.
It's more like you're saying that it should be impossible to get a door without a lock. It gets cold in the winter, I'd like a door. I'd like to be able to have some privacy in my bedroom, I need a door. Sure... that's less secure than having locks on those doors, but saying I shouldn't have the choice is absurd.
The threat profile isn't quite this simple.
First, if the attacker controls DNS he can probably succeed without any self signed certificate. All he needs to do is intercept the connection to the insecure bank home page and replace the log-in form with one that posts to http s://bank.com-------fakesite.com/ which he has a valid certificate for.
Second, the browser can warn about these certificate swapping attack by simply warning on every certificate change. This will help protect against MITM attacks for both recognized and unrecognized certificates as long as a user's first connection to a given site is hijacked (which isn't perfect, but it's a security improvement).
This is simply factually incorrect.
Remedial computer security lesson: The SSL protocal provides authentication and encryption. At the start of an SSL session the certificate is checked to authenticate the server and symmetric encryption keys are exchanged to encrypt the rest of the session.
In the article, I suggest that a site with a self signed certificate should be displayed with a white address bar, no lock, and a "this site cannot be authenticated..." info bar. How does that lead the user to a false sense of security?
This is true in theory and completely false in practice. Everyone and their dog has a wireless sniffer app. Hijacking a wireless connection is much more difficult.
Further, it wouldn't be too hard to provide practical warnings to the user in this case - if you store the certificate the first time you go to the site, you can flip out if it unexpectedly changes later.
Sure, a MITM attack trumps unauthenticated certificates. A phishing with similar URL attack or a trick-the-CA attack trumps an authenticated certificate.
A self-signed certificate is better than no certificate because it keeps out an attacker who can snoop but not hijack the connection. This is a common scenario, and worth protecting against.
Why should self-signed certificates be treated any worse than no certificate?
So far, I've heard about exactly one scenario where the current behavior would be better than simply treating a self-signed certificate like no certificate - if the attacker controls the user's DNS and the user is visiting a bookmarked https URL.
If an attacker controls your DNS, you've mostly lost already. If you don't have a bookmark to an https URL, the attacker can just point the form at another secure URL (with a valid certificate) or an insecure URL with the URL you expect.
Note that in the latter case (insecure but valid URL) the UI will look exactly the same as it would if Mozilla treated self-signed certificates like insecure sites.
How are they any more likely to get phished on a self-signed certificate than a valid certificate on the wrong URL or on the correct insecure (http) URL?
Snooping a connection is a hell of a lot easier and more common than hijacking one. Hell, if someone can arbitrarily hijack connections, they can get themselves a completely valid SSL certificate by demonstrating their (hijacked) control of the domain to some minor CA.
There are no perfect answers to these security problems. But there are wrong answers - and requiring website owners to always sign up and be approved before they can use the HTTPS protocal on a public website is a wrong answer.
Even then you can't be sure, because the hole could be built into the hardware. The best you can really do is get a stack of identical processors and chip sets and destructively slice all but one of them up and run them through an electron microscope to verify the circuits - but even then you'd only have a statistical guarantee and you still might miss some clever analogue circuitry trick.
To a first approximation, kidnapping child molesters don't exist. To a second approximation, every single person who might kidnap your child is a friend or family member - you and your child trust them, they won't need a net.
Remember: News is "something that almost never happens". Otherwise it wouldn't be news. If you see it on TV, you don't need to worry about it.
OK. Now that we're clear on where you stand, I can clearly present a conflicting view.
First, men and women really do learn differently. This isn't simply an issue of who gets more attention; the way the material is presented can make it easier for boys and hard for girls or vice-versa.
Second, this isn't "doing it wrong". The goal is to teach the students - if there is a way to present the material that makes it easy for girls it is best if girls are taught that way. Boys in the class are going to have a hard time, but it's better that some have an amazingly informative class than that everyone gets a mediocre class.
Personally, I think the best solution would be to test each student for learning style and then put them in a class with a teacher comfortable teaching in that style. My guess is that this will be very close to splitting by gender - but even if I'm wrong and boys and girls have identically functioning brains, this would still drastically improve education for everyone.
Now more attention is paid to girls (and material is taught in style that favors girls), and they do better in almost every area. The exceptions were mathematics, engineering, computing, and hard sciences.
If it's good that teaching-style change has made girls completely catch up in mathematics, then obviously you support a change in teaching style that will make boys catch up in biology and psychology - even if that makes it harder for girls - right?
Right. And obviously we want to be exchanging pieces of paper and database entries rather than lumps of metal. The question at hand is simply if money should be abstracting (backed by) physical assets like gold or iron or not.
The people with opinions on this topic seem to fall into three categories:
- Anti-statists, who think that governments can't be trusted with the power to create money out of thin air.
- Statists, who think that the idea of limiting governmental power is foolish.
- "Agents of inertia", who assume that there must have been a good reason to change off the gold standard and that anyone who is suggesting a change of direction is dumb and wrong.
That still leaves us without the basic information on what the *economic* benefits and disadvantages are of the two options and if there are other options that might be better than both.
No, but the effect of Mozilla's policy - for no actual user benefit - is to mandate that anyone who wants encryption must buy a certificate (from a specific list of vendors). And no, "but someone could offer certificates for free if they wanted to go through the audit process" is not an interesting argument.
Sure, Iron would work just as well, except for two things:
The fact that some people are confused about the meaning of a term doesn't mean that it has somehow lost its meaning.
Yes, a bit. The literal definition of "proprietary" is simply "having to do with property". As jargon in the software field, it means "controlled by a single entity".
Proprietary implies lock-in and monopoly. The opposite is an "open standard" where there can be a competitive market.
Think proprietary = monopoly, open = free market.
That's begging the question. I'm discussing what Mozilla's policy *should be*, and you're talking about the economics given a certain policy. Mozilla should act in the best interest of their users, not to maintain an high monetary price on encrypted browser sessions.
That's everyperson, don't be a sexist bastard.
Every site on the web that would be worth encrypting traffic to is a business?
Every site can budget either $10/host name or $300/domain (for a wildcard cert)?
Even if they can, they should be expected to pay those prices if the authentication service that the CA provides is completely irrelevant to their threat model?
None of those assumptions are true.
There is a good argument for tying the lock icon to certificates issued by major commercial certificate authorizes, but tying the actual encryption to it can only make the internet less secure.
How is that better than simply providing no indication that a site is self-signed at all?
All that the current "OMG HAX" warning does is prevents many connections from being encrypted, drastically reducing internet security overall.