IPv6 - The Death of SSL

Tuesday, October 04, 2011

Craig S Wright

8b5e0b54dfecaa052afa016cd32b9837

We see many sites moving more and more to application level encryption such that they can protect the transport of sensitive data. 

IPv6 is THE killer application for SSL. Not that SSL needs help, it is flawed.

IPv6 provides support for encryption within the protocol. This is a key differentiator when we compare it to IPv4 where encryption was provided by the application. IPSec can be used with IPv4.

That said, IPSec is tacked onto IPv4, it is fundamental to IPv6. The standards require mandatory IPSEC (with all the associated crypto code), it is not just an add on. IPv6 requires crypto.

On top of that, endpoint authentication is also provided in IPv6, something that was overlooked in IPv4.

IPv6 does not come even close to solving all the world’s security woes and nor could a simple protocol ever attempt to do such. That said, all it needs to do to kill off SSL is to:

  1. Be as effective as SSL or better,
  2. Have a wide deployment.
IPv6 will provide the later point. When IPv6 finally becomes the norm, IPSec will become ubiquitous. It will be deployed far wider than SSL ever was. Next, it simplifies things for developers. Crypto is difficult. Developers make mistakes again and again in implementing crypto. The centralised control and deployment of network crypto is a good thing.

As for being as good or better than SSL, well SSL is flawed. It was from the start and it remains flawed. This point is moot as it would be difficult to make the protocol worse.

IPSec allows the application to call for authentication separate from encryption for use in situations where encryption is prohibited or prohibitively expensive. This is, AH headers can provide integrity and end-point authentication without the overhead of encryption.

For most machines, Intel's decision to incorporate AES processing into the CPU will greatly alleviate the costs of encryption. This will not of course completely remove the CPU costs from large e-commerce websites, but it will make it simpler for the user of such a site.

New, SSL will have a particularly difficult time with many of the extensions that IPv6 is introducing. The new privacy extended IPv6 addresses generated CGA (cryptographically generated addresses) will:

  • maintain privacy
  • add accountability for link administrators
IPv6 will even add a Host ID can be used as a token to access to a network. The big issue is that we will expect multiple addresses per node, so “Who needs spoofing?”

The combination of multiple IP addresses and CGA makes a difficult time for existing implementations of SSL. We could determine to try and fix SSL, but the issue here is simply why?

IPv6 has encryption built in. The IPv6 Security Protocols include:

  • Authentication Header (AH) [RFC4302] and
  • Encapsulating Security Payload (ESP) [RFC4303].

These work through Security Associations. What a SA is and how they work, how they are managed, associated processing are all defined in [RFC4301].

The death knell for SSL really comes as the algorithms for authentication and encryption in IPv6 are defined as being mandatory. These algorithms are defined for use with AH and ESP in [RFC4835] and for IKEv2 in [RFC4307].

Basically, IPv6 already has a tunnelling and transport encryption protocol incorporated that has to be deployed. Why have SSL embedded within IPSec?
AH provides:

  • Integrity.
  • Data origin authentication.
  • Optional (at the discretion of the receiver) anti-replay features.
IPSec implementations MUST support ESP and MAY support AH.

ESP provides:

  • Integrity.
  • Data origin authentication.
  • Optional (at the discretion of the receiver) anti-replay features.
  • Confidentiality (NOT recommended without integrity).
On top of this, each IPSec implementation there is a nominal Security Association Database. The SA contains much more than I have included below, but this covers some of what is necessary for this post:

  • Each entry defines the parameters associated with one SA.
  • Each SA has an entry in the SAD.
  • The SPD has pointers to SAD entries, when IPSec have to be used (PROTECT).
  • Anti-Replay Window: A 64-bit counter and a bit-map (or equivalent) used to determine whether an inbound AH or ESP packet is a replay.
  • AH Information: Authentication algorithms, keys lifetimes etc.
Now, when you consider as well that [RFC4941] describes an extension to IPv6 stateless address auto configuration that makes nodes to generate global-scope addresses that change over time. We have multiple addresses per host that move, update change. We see that this standard allows:

  • The IPv6 addresses on a given interface generated via Stateless Auto configuration contain the same interface ID,
  • Occurs regardless of where within the Internet the device connects, and
  • This facilitates the tracking of individual devices.

Again, why would we bother with SSL?

Once a business starts to see that they have encryption and authentication services at the end-point and over the layer three level to and from the host and server, they will not bother with the notion of application layer security. As such, SSL will become redundant.

Why would a business have both a secure and an open web site? Why would they implement separate controls for email, the web, file sharing and all other applications they run.

No, simply put, SSL is flawed, but at least we can see a slow death as the uptake of IPv6 replaces the existing IP stacks host by host.

About the Author:

Craig Wright is the VP of GICSR in Australia. He holds both the GSE, GSE-Malware and GSE-Compliance certifications from GIAC. He is a perpetual student with numerous post graduate degrees including an LLM specializing in international commercial law and ecommerce law, A Masters Degree in mathematical statistics from Newcastle as well as working on his 4th IT focused Masters degree (Masters in System Development) from Charles Sturt University where he lectures subjects in a Masters degree in digital forensics. He is writing his second doctorate, a PhD on the quantification of information system risk at CSU.

Possibly Related Articles:
30985
Encryption SSL IPv6 IPv4 Tunneling IPSec
Post Rating I Like this!
Default-avatar
Uli Gue Perhaps, Mr Craig Wright forgot that SSL is also used at Certification Authorities, not only at channel encryption. IPv6 encrypts frames while SSL encrypts the payload. A top-secret message under IPv6 must be encrypted during it travels Internet but must be kept under secret form after it is stored. And a little bit more. IPv6 implements several encrypting algorithms? No! It does not! So, look at all operational scenario before a hard affirmation like you did. Intel procedures will increase the IPv6 performance but will not solve situations like as in cellular chips, neither storage. Perhaps the article may be incomplete. Mr Wright, you have the word.
1318401505
8b5e0b54dfecaa052afa016cd32b9837
Craig S Wright "IPv6 implements several encrypting algorithms?"

Actually, IPv6 has many choices of algorithms.

"Mr Craig Wright forgot that SSL is also used at Certification Authorities"

I think you should reword this. Basically it makes no real sense in the existing form.

"IPv6 encrypts frames while SSL encrypts the payload."
I suggest you read more on AH and ESP in IPSec.

"IPv6 must be encrypted during it travels Internet but must be kept under secret form after it is stored"
Neither SSL nor IPv6 has ANYTHING to do with encryption on disk. It is only in transit.

@Uli I think you have confused what SSL does for a start...

1318403126
Bd623fa766512fdf6b57db66f522b741
Ali-Reza Anghaie I think we're making the issue too complex on one hand and too simple on the other. I'll just touch on some areas below but it's a much larger discussion being had all over the place:

- We should try to separate protocol/specification from practical application (cont. below).

- SSL/TLS in-and-of-itself has flaws and then it has flaws due to poor application through bad Certificate Authority design or misguiding trust in DNS (DNSSEC), etc. IPv6 doesn't magically make the later go away by any means. The issues of trusts, distribution of keys, etc. all still exist. No because IPv6 was designed flawed per se but because it's not trying to address application layer nor the growing usage areas SSL/TLS have been applied to.

- IPv6 is still growing and (in practice) organic, we've yet to see how IKEv1 IKEv2 IPSECKEY (oh, there is that trust in DNS again) etc. all work in practice on a GRAND scale. So while they ~may~ well be understood as replacements for, say, a SSL VPN solution, it's not clear that a HTTPS replacement is present.

- SSL/TLS provides more granular per-user and per-application/process controls for multiple users on the same host that IPv6/IPsec don't readily address. Can it? Perhaps but it's not evident how and the numerous proposals to do such are a far cry from the standard mechanisms known and well understood w/ SSL/TLS today.

And none of that addressed the simply maturity cycle that IPv6 must undergo at implementation and practice levels.

IPv6 suffers the same basic problem SSL/TLS does in that where and how to ~use~ it is still misunderstood. It also suffers from marketing right now and a general impression being left among many professionals that IPv6 is a panacea for what ails the Internet.

SSL/TLS or evolved equivalents will have a place alongside IPv6. And discussions about CAs, DNSSEC, DANE, and more innovative approaches like Moxie's Convergence still need to be had in an IPv6 world ~anyway~.

And frankly, the way things are going, we might all be really old men before IPv4 is retired (enough) to have decided what's best to do. -Ali
1318435446
Default-avatar
Uli Gue Thank you, Mr Ali-Reza Anghaie. That is the point.
1318436778
8b5e0b54dfecaa052afa016cd32b9837
Craig S Wright "SSL/TLS provides more granular per-user and per-application/process controls for multiple users on the same host that IPv6/IPsec don't readily address. Can it?"

Actually, IPv6 CAN do this. ESP and AH tunnels can be set per host, per port/protocol and more.

In fact, a single host can even have multiple IPv6 addresses and have 64k IP addresses all used for separate connections if you wish to make it that complex.

In fact, you can do far more granularity with IPv6 then was ever planned for in SSL. Think of the issues with multiple IP addresses in SSL/TLS. There are ways to make this work, but the support remains limited.

CAs remain an issue, but there are other mechanisms. I will be discussing these in coming posts bit by bit.

As for "old man", well if that is in the next few years as it is already rolling out. We are out of IP ranges to allocate over here in Au and Asia has more connections each year. It has taken a long time, but .gov connections are already popping up and it will not be too much longer.

DNS remains an issue. IPv6 does not solve all of the world's ills.

"IPv6 suffers the same basic problem SSL/TLS"
If you think I am saying this is a magic bullet, I am not. IPv6 CAN make things better, it can also make it far worse as it makes the traditional approaches to security fail (no more crunchy shell).
1318451984
8b5e0b54dfecaa052afa016cd32b9837
Craig S Wright Honestly, if you think we can keep going using IPv4 for much longer, you have not been watching the market.

I have seen plans to have RFID printed into FMCGs. There are technologies that allow this.

Think of having a bottle of milk with an IP address. If that seems to far fetched, well I already know of projects to do just that. Inventory control and management. Shopping 2.0.

It is already in progress, and the simple answer is we cannot do this with v4.
1318452385
8b5e0b54dfecaa052afa016cd32b9837
Craig S Wright @Ali-Reza I guess that you do not realise that you CAN have a separate tunnel for each and every application, user, transaction and more with IPv6.

You can have AH used for integrity and transmission of data that is public when at the same time having an ESP tunnel for authentication.

With that stated, you can also build in authentication to the protocol stack.

I will be posting how this is and can be done, but there is only so much time to write in any day :)
1318452620
8b5e0b54dfecaa052afa016cd32b9837
Craig S Wright @Uli I will be posting far more on IPv6 in coming posts. What you need to remember is that IPSec does not fix ALL security concerns. Humans still make mistakes (no technology will stop this).

In looking at SSL vs IPSec in IPv6, the comparison is just on those two protocols and their flaws etc.

Things such as on disk encryption are irrelevant. Neither SSL NOR IPSec has anything to do with this. The comparison is from one transport method to another.

Both IPv6 and SSL have trust issues. There are methods to make some of this moot already, but the issue there comes to what that means for privacy. Issues of Trust and DNS do not go away due to IPv6 and nor did I say they would, rather, as IPv6 can be configured in a far more granular manner and is not application specific, it has benifits over SSL.

More, IPSec will be a part of the IPv6 world. You NEED IPSec if you move to IPv6.

@ Ali-Reza Saying there are issues with mobile devices is short sighted at best. The growth of computing power is exponential and will continue to be for the foreseeable future. Issues of computational power and battery life have a solution. To believe otherwise is very short term thinking.

So, adding extraneous issues does nothing to further a discussion on whether SSL will be replaced by IPv6.

SSL will be replaced as software vendors do not do crypto well and the fewer implementations of it, the better. IPv6 allows for the O/S to handle this and leaves browsers and more to concentrate on their core function.
1318453629
Bd623fa766512fdf6b57db66f522b741
Ali-Reza Anghaie OK, you just flopped out a bunch of responses so lets work backwards:

- Where did I say anything about mobile devices, compute power, or battery life being an issue? I don't think you were responding to me.

- Your point about software vendors not doing crypto well actually supports my general point. Again. You're trying to tie a set of standards into the actual ways people use them. Nobody reinvents OpenSSL anymore but plenty of people use it poorly. That doesn't change one iota whether they're calling existing defacto standards libraries or each vendor's implementation of IPv6. For the near term is actually further exasperates the problem due to the maturity and difference in implementations I noted in my original response.

- Again, I was VERY specific in what I said. And I added the opening bullet to try to avoid further confusing the issue:

"We should try to separate protocol/specification from practical application" !!!

- There are envisioned ways to do EVERYTHING w/ IPv6. Again, "but it's not evident how and the numerous proposals to do such are a far cry from the standard mechanisms known and well understood w/ SSL/TLS today." And just because they're envisioned doesn't mean it's a good idea to merge those two disparate target solutions. History has demonstrated that's actually a bad idea (SSL's own history or NAT for example).

You effectively prove that point with your response up from that in how you will outline it. Everyone is PROPOSING options rights now for an IPv6 world. For years well into an IPv6 world I can and will grab SSL/x509/etc. and do my two-factor certificate (*cringe*) authentication through the browser voila. It's more generally applicable and portable in implementation today. That isn't going to go away because of IPv6, it's not ~that closely~ related in implementation and practice. For IPv6 a lot of the supporting systems and processes still have to be created and to just toss crypto/integrity/security onto the IPv6 stack is shortsighted.

- I didn't for one moment suggest IPv4 was going to stick around although I don't buy into the idea of mass chaos any day now from address exhaustion. I was just observing that the in-between layer solutions, in this case SSL/TLS, aren't DIRECTLY comparable to IPv6. FTP and Telnet suddenly don't become secure through IPv6 (nor did you say they would, I'm just providing examples).

OK.. now I'm reading further up and it seems you're avoiding admitting you made too broad a general statements prematurely. NOW you're talking about actual remaining problems to be solved and how you're going to talk about solving them.

*face palm* *palm face*

I didn't assume you were saying it was a panacea, I was noting the general impression a lot of professionals are left with that it ~is~. AND (here is the original point, lets try again) if you try to compare SSL to IPv6 without talking about APPLICATION and use and practical aspects like administration (CAs, DNS, etc.) then you're completely misleading the conversation into another pit of doom.

I believe, by your first response to me (last one I read), you fully understand this. Good. We're on the same page there now.

So lets not draw direct comparisons w/o at least acknowledging that they are totally different breeds of beast for different problems. Or making implications (say of BEAST) that are FAR less important than ones like Certificate Authorities which IPv6 DOES NOT solve today in ~actual implementation and practice~. Not theoretical, actual available ORA book, across all major platforms and carriers, ~practice~.

Now that (I think) I'm understanding where you're going with this. Are these discussions you have kicked off on NANOG, cryptography, SSL observatory, ipv6 & ipv6-wg mailing lists?

So, back to my opening line:

"I think we're making the issue too complex on one hand and too simple on the other."

Let me make a suggestion... in both your SCADA related series and this one you've responded saying you're going to address these issues. May I suggest then that you label and write your articles as such? Perhaps part of an "ongoing series" you're producing on the topics?

If indeed you intend to address all these issues and you're aware of them, and it certainly appears that you are, then you're not reflecting that with your dismissive statements like:

"Again, why would we bother with SSL?"

That's enough from me on this issue, I wasn't here to say SSL and IPv4 will ride into the future and bury IPv6. This wasn't an argument, I was trying to bring a broader perspective to the table. *shrug*

I look forward to your other unrelated (related?) correspondance via email. Cheers, -Ali
1318458884
8b5e0b54dfecaa052afa016cd32b9837
Craig S Wright @Ali-Reza "OK.. now I'm reading further up and it seems you're avoiding admitting you made too broad a general statements prematurely. NOW you're talking about actual remaining problems to be solved and how you're going to talk about solving them."

At no point did I state that IPv6 makes all the security ills of the world go away.

The issue is far simpoler tahn you are attempting to make it. Logically, we can break it into a series of suppositions:

1 IPv6 will be deployed widely in the near future.
2 IPv6 has manditory encryption through IPSec.
3 IPv6 with IPSec has trust issues, some of these are the same as those in SSL. This is irrelivant to the arguement as SSL offers nothing as an improvement - just another stack.


You may not like to believe (1), but this does not matter. It is already in progress.

IPSec and SSL each have many of the same flaws. This does not mean that point (2) is invalidated. Rather, the trust issues remain and there are fewer crypto stacks to worry about with IPv6. Right now, the browser, JRE, Flash and more all have crypto. They all have flaws. Less software = fewer holes.
Crypto is hard and developers make big mistakes.

OK.. now I'm reading further up and it seems you're avoiding admitting you made too broad a general statements prematurely. NOW you're talking about actual remaining problems to be solved and how you're going to talk about solving them.
"
"We should try to separate protocol/specification from practical application" !!!

I am talkjing of practicle applications. This IS starting to be applied now. Existing systems.

Yes, everyone uses OpenSSL, with separate libraries that all need separate updates. More issues and patching.

"For IPv6 a lot of the supporting systems and processes still have to be created and to just toss crypto/integrity/security onto the IPv6 stack is shortsighted."

Yes, they have to be created. That is a part of the point. Many things we have not are set to change in the coming decade.

"FTP and Telnet suddenly don't become secure through IPv6"
No, BUT FTP and Telnet CAN be tunneled BY DEFAULT using Group Policy, Linux Firewalls and more. That is, insecure telnet CAN be make to use a tunnel. I have already seen this implemented and used.

"Perhaps part of an "ongoing series" you're producing on the topics?"
Yes, I will label them as such.
1318461600
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.