Recent Blog Entries
Beware Chrome and HTTP/2 Debugging April 2 2023
It’s About Security, not Privacy Feb. 26 2016
Technology Marches On Feb. 18 2016
Bitcoin: Where is the Governance? March 3 2014
Bitcoin March 1 2014
I was recently asked to compare IPsec (Encryption of IP Packets at the IP network layer) vs. SSL/TLS (the technology behind https links). Here is my response:
If I look at IPsec vs. TLS as an engineer, IPsec (or its refinement) is closer to the right thing. By being in the kernel, it has access to headers so it can protect them. SSL/TLS cannot do that.
One of the hangups we kept having in the IETF was the insistence of looking at every problem exclusively through the lens of an engineer and not of a business person (or politician!).
IPsec was doomed from the start. Although loved by (some) engineers, engineers for the most part don't decide what gets built (well, maybe in the open source world, but the OS world of the 1990's was dominated by commercial players). Engineers build what their bosses tell them to. Their bosses tell them to build the things that the customers ask for.
Customers were not asking for a security layer in their computers. In fact there was no active constituency for security *anywhere*. People at some level want security, but were satisfied with smoke, mirrors and vague assurances. Deploying IPsec would be a nightmare, it would result in a lot of things just not working for unknown (to the users) reasons. We see this today with deployments of IPsec for secure work at MIT. It would be a support nightmare for the OS vendors (or network people) and it would provide no benefit (aka people won't pay for it) to those vendors.
SSL succeeded because Netscape had a vested interest in making it work (they wanted to profit from commerce on the Internet) and were in control of the code necessary to make it work. They controlled the Netscape browser *and* the Netscape Commerce server (which is where they wanted to make money). As long as the Netscape Browser could talk to the Netscape Commerce server, they were set. So in this case the business case for SSL was there. Fortunately for the rest of us we were able to get SSL standardized into TLS, get Microsoft on board (which was developing their own equivalent, I believe called PCT), and get everything to interoperate. I won't take complete credit for that, but I certainly helped. When I became the IETF Security Area Director, getting TLS standardized was one of my key priorities.
In spite of a its faults, the primary of which is its dependence on a PKI that cannot work before the ocean is boiled (I'll write about that in another message, maybe today, maybe not), TLS/SSL (https) is a tremendous success. As bad as things may be vis. a vis. from a security standpoint on the Internet today, they would be much worse if it weren't around.
All that said, I am currently a believer in the HTTPS Everywhere campaign of the EFF. I believe this will help improve the overall security of the Internet, and more importantly, I believe it is an achievable goal. I don't believe getting IPsec universally deployed is currently realistic. Too much ocean to boil for that one.
From: Anonymous Coward
A significant advantage of TLS/SSL is that it was integrated with the application (e.g. web browser) in application space, unlike IPsec which normally is a OS kernel service that might be invoked by an application using some OS/network API. This means that IPsec likely would have benefited from more standards work in the API area.
Copyright © 2009-2023 Jeffrey I. Schiller