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?
"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.