Triple DES is, for practical purposes, as secure as 128 bit AES and 256 bit AES. 256 bit AES has flaws in its key schedule routines, which at the moment make it slightly easier to brute force than 128 bit AES, but still impractical.
The problem that drove the development of AES is that the performance of Triple DES sucks.
I'm not sure when it happened, but a lot of sites like NetFlix started doing these side-ways scrolling interfaces and it's just annoying and difficult to navigate.
It happened about the same time everyone started buying widescreen monitors, laptops and tablets. Widescreen might be great for watching films, but it's dreadful for reading text.
If you need address space randomization, you're already broken. It just makes the dumber stack overflow exploits crash more.
Defence in depth is a very good security practice. You accept that the first line of defence isn't going to be perfect, and build redundancy into the system.
As for the limitations of Apple's approach, then I'd suggest reading Jonathan Zittrain's The Future of the Internet - and how to stop it. He spends a lot of time discussing the attractiveness of "walled garden" systems and how similar benefits could be gained in open systems.
It is utterly amazing the number of websites that can't render a page without firing scripts or loading content from 6, 8, 10 or more different domains
Is tunnelling "every protocol known to man" over HTTP the answer? If you allow HTTP through the firewall today, you're essentially allowing anything. If the firewall blocks RTSP, it's probably because the owner of the network didn't want all the bandwidth taken up by realtime streaming media...
You seem to be misunderstanding the SSH protocol in this case, and seem to be assuming it protects you in a way that is doesn't.
I know exactly what the protocol does and doesn't protect me from. I also watch how normal people use computers. I've watched people blindly accept the warnings from PuTTY when servers have been rebuilt or had their SSH keys regenerated. I've also seen people blindly ignore certificate errors. I would like to be able to walk into my bank and verify the fingerprint of their SSL certificates with them directly, but I doubt they would have a clue what I was talking about.
Once the certificate is accepted SSH protects you from MitM and other attacks by protecting you against the certificate changing
Firefox extensions such as Certificate Patrol provide similar functionality for SSL certificates (self-signed and those signed by CAs).
I could name one company (a defence contractor) who does this in their transparent proxy for all outgoing connections so they can monitor for trade/state secrets being passed around that way (and their machines trust their own internal CA cert, so the proxy can generate valid looking certs for anyone's services (even, for instance, Google's) and browsers on their network wouldn't know).
My understanding is that there are banks who do this too for similar reasons.
The benefit is small though, and there is a potential significant cost to accepting self-signed certs without warning
Compared to unencrypted connections? I can log in to a website over plain HTTP without any warning from Firefox. If the site were to use a self-signed certificate and I tried to log in over HTTPS I would get a big scary warning. That seems the wrong way around to me.
With a certificate with a proper trust chain you know every connection, even the first, is very very very unlikely to be MitMed
That's good in theory. The issue this has highlighted is that the trusted third parties can't be trusted to reliably do their job. A look through Firefox's root certificates lists Comodo (who, not for the first time, have issued certificates to the wrong people), Verisign (who I don't trust thanks to Site Finder) and BT (who I don't trust thanks to Phorm). There are probably many on Slashdot who don't particularly trust Dell, Google and Microsoft either. This is why I much prefer PGP's web of trust approach to X509's strict hierarchy.
And what if the site's certificate changes?
One of the nice things about Certificate Patrol is it highlights all changes to certificates since the last visit, and flags if the previous certificate was approaching its expiry date. If my bank's site suddenly changes from being signed by Verisign to signed by Comodo despite having 6 months left on the old certificate, Certificate Patrol will throw a warning.
dsniff was released over 10 years ago and does what you suggest. OpenSSH still works fine using the equivalent of self-signed certificates.
A number of ISPs seem to think that snooping on their customers' traffic for things like Phorm is acceptable. How many of them would think they could get away with forging SSL certificates? On every connection their customers make?
I've never said self-signed certificates are perfect, only that they do offer benefits over unencrypted connections. What benefit does a StartSSL certificate have over a self-signed certificate when accessing a random web forum run by someone I've never heard of? So what if StartSSL assures me it's run by someone called Joe Bloggs, why do I care? What security does it buy me over and above a self-signed certificate? How about compared to the self-signed certificate my browser stored when I initially signed up to Joe Bloggs' forum?
Do you think this will be applied uniformly to all companies, or do you think it'll only be enforced against companies that are Microsoft's competitors?
What do you think will happen when one of HP's hypothetical suppliers in Taiwan is found to be using pirated software? How about the Taiwanese supplier's other US customer, who happens to make Android mobile phones?
All you can ever do is make the attack harder/riskier/more expensive. Self-signed certificates make a trivial attack harder. Tracking what certificates a site used and warning if it has changed (the same approach openssh uses), gives almost all the benefit the CAs give. Yes some users will ignore the warnings, but they'll also ignore the warnings about expired certificates, certificates with the wrong commonName, etc. As this story shows, the CAs themselves are far from perfect and often don't live up to being called "trusted third parties".
I wouldn't trust my financial information to a connection using a new, never seen before, self-signed certificate, however they do introduce security benefits over plain HTTP. The fact that self-signed certificates lead to Firefox to issue scary warnings when unencrypted connections don't is ridiculous.
With unencrypted HTTP, any one who can see the packets can snoop the whole session.
With SSL/TLS, with a self-signed certificate, the attacker has to be in a position to tamper with the packets. The attacker has to impersonate the server to the client, and potentially the client to the server (depending on the attack). This is a much harder problem than simply sniffing the traffic with tcpdump.
Anyone on a public WiFi network can sniff the packets of other users on the WiFi network. It would be very difficult to pull off an attack on a self-signed SSL connection.
They just slap Oracle logo on Red Hat, do not acknowledge the source and sell is as "unbreakable Linux"
I think you'll find Oracle have to do it that way thanks to Redhat's trademark licensing. Oracle have to completely rebrand RHEL, and have to be very careful when referencing Redhat in any way.
Have you never noticed how CentOS never states it's derived from RHEL, only from source from a "prominent North American Enterprise Linux vendor"? Redhat's trademark licensing...
If the answer returned doesn't have a valid signature, DNSSEC would return SERVFAIL rather than the IP address. DNSSEC can only verify you got the right answer - it turns faked responses into a denial of service. If this case, a denial of service is exactly what the attacker (i.e. the ISP) wants.
The Uni of Bath library used to have a small number of Sun X Terminals for checking email. They were great for when all the PCs were in use during the day, as only a small number of us knew how to use them and how to break out of Pine and run Mozilla.
Water bills in the UK were governed by the "rateable value" of the house. Water meters were introduced about 15-20 years ago and are required for new houses. Older properties can choose to have a meter installed or to remain on the rateable value billing.
SIP doesn't even traverse NAT firewalls without help from outside, and even then, barely
The problem here is NAT, not SIP. The solution is IPv6 and reintroducing end-to-end connectivity.
SIP is also only the signalling protocol. The actual multimedia streams are usually RTP, so the jitter you refer to is nothing to do with SIP.
The "OS" is less and less an OS. It is increasingly becoming an application that runs on top of another OS (VMWare/Xen/etc). It's the VM layer that handles all the things OS's traditionally handled, like the hardware device drivers and resource management.
The only top level domains should be the country code TLDs. Each TLD could then be delegated to the appropriate government to manage and control as they see fit. The USA shouldn't impose its standards on other TLDs any more than Iran should be imposing its standards on the USA domains.
If the USA wants an XXX domain (for example), let them have xxx.us and they can do what they like with it.
DNS is all about delegating subtrees to other authorities.
Slashdot Mirror
Triple DES is, for practical purposes, as secure as 128 bit AES and 256 bit AES. 256 bit AES has flaws in its key schedule routines, which at the moment make it slightly easier to brute force than 128 bit AES, but still impractical.
The problem that drove the development of AES is that the performance of Triple DES sucks.
I heard it was some bloke called Archie Duke, who shot an ostrich because he was hungry?
It happened about the same time everyone started buying widescreen monitors, laptops and tablets. Widescreen might be great for watching films, but it's dreadful for reading text.
Defence in depth is a very good security practice. You accept that the first line of defence isn't going to be perfect, and build redundancy into the system.
As for the limitations of Apple's approach, then I'd suggest reading Jonathan Zittrain's The Future of the Internet - and how to stop it. He spends a lot of time discussing the attractiveness of "walled garden" systems and how similar benefits could be gained in open systems.
The purpose of the experiment is to see what problems actually appear.
I expect Google know this - they recently implemented happy eyeballs in Chrome, and I believe similar functionality is also in Safari.
See IPv6 in Google - A Case Study (PDF) for an idea as to what Google are already measuring, and how.
You can partially blame Google for that - "Serving resources from two different hostnames increases parallelization of downloads".
Is tunnelling "every protocol known to man" over HTTP the answer? If you allow HTTP through the firewall today, you're essentially allowing anything. If the firewall blocks RTSP, it's probably because the owner of the network didn't want all the bandwidth taken up by realtime streaming media...
Firstly, that's Penrith Station in Cumbria, UK. Secondly, it's 'shopped. The real signs say "Passing trains cause air turbulence".
"Tax haven" is a common term in UK English. Is the term not common in the US?
I know it's only an example, but Verisign and Thawte are the same company, and according to Wikipedia, they're both now owned by Symantec.
If you advertised your kitchen knives based on how amazingly good they are for stabbing people, then I would expect that advert to be banned too.
It was the advert that the Advertising Standards Authority banned, not the device.
I know exactly what the protocol does and doesn't protect me from. I also watch how normal people use computers. I've watched people blindly accept the warnings from PuTTY when servers have been rebuilt or had their SSH keys regenerated. I've also seen people blindly ignore certificate errors. I would like to be able to walk into my bank and verify the fingerprint of their SSL certificates with them directly, but I doubt they would have a clue what I was talking about.
Firefox extensions such as Certificate Patrol provide similar functionality for SSL certificates (self-signed and those signed by CAs).
My understanding is that there are banks who do this too for similar reasons.
Compared to unencrypted connections? I can log in to a website over plain HTTP without any warning from Firefox. If the site were to use a self-signed certificate and I tried to log in over HTTPS I would get a big scary warning. That seems the wrong way around to me.
That's good in theory. The issue this has highlighted is that the trusted third parties can't be trusted to reliably do their job. A look through Firefox's root certificates lists Comodo (who, not for the first time, have issued certificates to the wrong people), Verisign (who I don't trust thanks to Site Finder) and BT (who I don't trust thanks to Phorm). There are probably many on Slashdot who don't particularly trust Dell, Google and Microsoft either. This is why I much prefer PGP's web of trust approach to X509's strict hierarchy.
One of the nice things about Certificate Patrol is it highlights all changes to certificates since the last visit, and flags if the previous certificate was approaching its expiry date. If my bank's site suddenly changes from being signed by Verisign to signed by Comodo despite having 6 months left on the old certificate, Certificate Patrol will throw a warning.
dsniff was released over 10 years ago and does what you suggest. OpenSSH still works fine using the equivalent of self-signed certificates.
A number of ISPs seem to think that snooping on their customers' traffic for things like Phorm is acceptable. How many of them would think they could get away with forging SSL certificates? On every connection their customers make?
I've never said self-signed certificates are perfect, only that they do offer benefits over unencrypted connections. What benefit does a StartSSL certificate have over a self-signed certificate when accessing a random web forum run by someone I've never heard of? So what if StartSSL assures me it's run by someone called Joe Bloggs, why do I care? What security does it buy me over and above a self-signed certificate? How about compared to the self-signed certificate my browser stored when I initially signed up to Joe Bloggs' forum?
Do you think this will be applied uniformly to all companies, or do you think it'll only be enforced against companies that are Microsoft's competitors?
What do you think will happen when one of HP's hypothetical suppliers in Taiwan is found to be using pirated software? How about the Taiwanese supplier's other US customer, who happens to make Android mobile phones?
All you can ever do is make the attack harder/riskier/more expensive. Self-signed certificates make a trivial attack harder. Tracking what certificates a site used and warning if it has changed (the same approach openssh uses), gives almost all the benefit the CAs give. Yes some users will ignore the warnings, but they'll also ignore the warnings about expired certificates, certificates with the wrong commonName, etc. As this story shows, the CAs themselves are far from perfect and often don't live up to being called "trusted third parties".
I wouldn't trust my financial information to a connection using a new, never seen before, self-signed certificate, however they do introduce security benefits over plain HTTP. The fact that self-signed certificates lead to Firefox to issue scary warnings when unencrypted connections don't is ridiculous.
With unencrypted HTTP, any one who can see the packets can snoop the whole session.
With SSL/TLS, with a self-signed certificate, the attacker has to be in a position to tamper with the packets. The attacker has to impersonate the server to the client, and potentially the client to the server (depending on the attack). This is a much harder problem than simply sniffing the traffic with tcpdump.
Anyone on a public WiFi network can sniff the packets of other users on the WiFi network. It would be very difficult to pull off an attack on a self-signed SSL connection.
I think you'll find Oracle have to do it that way thanks to Redhat's trademark licensing. Oracle have to completely rebrand RHEL, and have to be very careful when referencing Redhat in any way.
Have you never noticed how CentOS never states it's derived from RHEL, only from source from a "prominent North American Enterprise Linux vendor"? Redhat's trademark licensing...
If the answer returned doesn't have a valid signature, DNSSEC would return SERVFAIL rather than the IP address. DNSSEC can only verify you got the right answer - it turns faked responses into a denial of service. If this case, a denial of service is exactly what the attacker (i.e. the ISP) wants.
How long will it be until they start intercepting all traffic on port 53 and sending it to their own DNS servers?
The Uni of Bath library used to have a small number of Sun X Terminals for checking email. They were great for when all the PCs were in use during the day, as only a small number of us knew how to use them and how to break out of Pine and run Mozilla.
Water bills in the UK were governed by the "rateable value" of the house. Water meters were introduced about 15-20 years ago and are required for new houses. Older properties can choose to have a meter installed or to remain on the rateable value billing.
The problem here is NAT, not SIP. The solution is IPv6 and reintroducing end-to-end connectivity. SIP is also only the signalling protocol. The actual multimedia streams are usually RTP, so the jitter you refer to is nothing to do with SIP.
Is that you, Tanenbaum?
The "OS" is less and less an OS. It is increasingly becoming an application that runs on top of another OS (VMWare/Xen/etc). It's the VM layer that handles all the things OS's traditionally handled, like the hardware device drivers and resource management.
The only top level domains should be the country code TLDs. Each TLD could then be delegated to the appropriate government to manage and control as they see fit. The USA shouldn't impose its standards on other TLDs any more than Iran should be imposing its standards on the USA domains. If the USA wants an XXX domain (for example), let them have xxx.us and they can do what they like with it. DNS is all about delegating subtrees to other authorities.