I've personally seen people click through the most alarming-looking certificate errors and start entering their bank login credentials. I've driven in cars with people who had put up with that knocking sound in the engine for months because it wasn't getting any worse. If your mother did any of these things, I would be very worried about her financial and physical safety.

You don't have to know how either works to recognise something is wrong with them. My mother, happily, is quite cautious and would go and find someone who understands the machine better. In the computer case, I'd likely be getting a phone call.

The certificate errors are kind of a design failure. Users are so used to clicking through messages they don't really understand, and this is just one more. Even the most alarming certificate errors are usually innocuous, in my experience - someone forgets to renew a certificate, or fails to get a new one for a domain change. That doesn't mean it's OK to ignore them, but we really need systems that don't cry wolf unless there's a really good chance that there's a wolf.

> Even the most alarming certificate errors are usually innocuous, in my experience - someone forgets to renew a certificate, or fails to get a new one for a domain change. That doesn't mean it's OK to ignore them, but we really need systems that don't cry wolf unless there's a really good chance that there's a wolf.

How do you propose to algorithmically determine if a certificate not matching a domain change is innocuous? This is a bit like suggesting having a "check engine" light that only comes on when there's an immediate risk of an engine fire.

For starters, there are a whole load of conditions that are no less secure than a standard http connection, such as self-signed certificates. But in those cases, the browser throws up a huge and misleading warning about it being insecure. Insecure is the default on the web: we should focus on positive signs that a site is secure.

Secondly, the system should make it harder for the administrator to make mistakes. For instance, the web server could refuse to serve https on a domain that it didn't have a certificate for. Or when a certificate nears its expiry date, the administrator should be getting plenty of reminders about it.

Thinking bigger, what if we tied it closer to the sensitive UI? What if only pages loaded securely could show a password field? What if rather than typing credit card numbers into boxes on a webpage, we were used to using a special browser interface that would only light up on secure pages?

Malicious intent can be algorithmically determined by checking for packets with the "evil" bit set to 1, as specified in RFC 3514 [1].

[1] http://www.ietf.org/rfc/rfc3514.txt

That is a horrible specification.

"Multi-level insecure operating systems may have special levels for attack programs; the evil bit MUST be set by default on packets emanating from programs running at such levels. However, the system MAY provide an API to allow it to be cleared for non-malicious activity by users who normally engage in attack behavior."

This should say that the system MUST provide such an api. Otherwise, a you can find a situation where the reciever may have to allow evil packets to pass, because they are sent by a user who has no option of setting the evil bit to 0 for non-malicious activity. Kind of defeats the point.

"Fragments that by themselves are dangerous MUST have the evil bit set. If a packet with the evil bit set is fragmented by an intermediate router and the fragments themselves are not dangerous, the evil bit MUST be cleared in the fragments, and MUST be turned back on in the reassembled packet."

This places an undue burden on intermediate routers, as they now have to parse the packets and determine if a fragment is evil.

"Intermediate systems are sometimes used to launder attack connections. Packets to such systems that are intended to be relayed to a target SHOULD have the evil bit set." These packets are not 'evil' in any technical sense. They are only a request for another computer to send evil packets.

"In networks protected by firewalls, it is axiomatic that all attackers are on the outside of the firewall. Therefore, hosts inside the firewall MUST NOT set the evil bit on any packets."

This is just stupid. If I am attempting to send malicious packets from within the firewall, I am already required to set the evil bit. Now I am also required not to. If I am sending a non malicious packet, I am already required to set the evil bit to 0.

Also, If I am on a computer behind a firewall, and attempt to send malicious packets to a computer outside of my firewall, I am still forbidden by this to set the evil bit. This will force attackers to either, break the spec, or give up their own firewall.

"Because NAT [RFC3022] boxes modify packets, they SHOULD set the evil bit on such packets. "Transparent" http and email proxies SHOULD set the evil bit on their reply packets to the innocent client host." I must be mis-understanding this one, becuase non of those uses seems evil.

"Devices such as firewalls MUST drop all inbound packets that have the evil bit set. Packets with the evil bit off MUST NOT be dropped. Dropped packets SHOULD be noted in the appropriate MIB variable." Dropping packets is a technichal inevitability, and a crucial part of TCP's anti-congestion stragety.

Just becuase the evil bit sounds like a good idea, does not mean we should go ahead and implement it without carfully looking at the technical implecations of the spec.

The problem with the car analogy, as TallGuyShort points out, is that cars are not capable of having as strong an influence over our lives as computers are. When I think about how this used to be done before, usually finances were done over phone where people got to talk to other people who explained to them things that they did not understand.

I agree that learning about SSL is probably overkill; but we do need more computer literacy among the general population. Think of it like this: finance is something that is hard, yet people learn about the basics so that they can keep their money safe. Basic computer literacy should have a similar status as a skill that is required to, say, keep your information safe.

I think the analogy is better than you are giving credit. I would say cars can in fact have much stronger influences in our lives than online banking can. For example, cars are much more likely to kill you. It's a much more important skill to recognize when your brake pedal is getting squishy so that it doesn't fail when you are careening down a mountain road, or recognize that an oncoming car is swerving erratically, than it is to realize you are logging in to an insecure phishing site. In the former case you end up dead, in the latter case your checking account gets wiped.

To clarify, when I say "learn about SSL", I mean people should know how to tell if the connection is "secure" or not, and that secure ensures that there is an extremely high probability that the domain they are talking to is who they say they are, as verified by some people that Google / Microsoft / Mozilla decided were trustworthy. Similarly, I think people should understand that emails can travel unencrypted between sites and are easily spoofed. I'm not saying they have a working knowledge of the RFCs for SSL and SMTP. I agree with the way you worded it - perhaps I made it sound too involved.

edit: another, perhaps more humorous example. How many times have you heard about people "hacking" their Facebook accounts and getting "viruses" on Facebook. I've been asked by multiple people to fix their computers, when the real problem was they had no idea what they were doing on the Internet.