Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Beyond stunnel: High-speed, secure connections across the public Internet

blog.vcider.com

Post reply on HN
Print view View original

1–10 of 20 posts

Beyond stunnel: High-speed, secure connections across the public Internet

#1

Post by jbrendel »

The standard ways to secure connections across public links (even for applications that don't support encryption themselves) has been to use stunnel or OpenVPN. But those solutions come with a significant performance hit. This article presents measurements and comparisons to illustrate this and presents a more modern solution with much better performance characteristics.

Beyond stunnel: High-speed, secure connections across the public Internet
blog.vcider.com

Re: Beyond stunnel: High-speed, secure connections across the public Internet

#2

Post by jbrendel »

The standard ways to secure connections across public links (even for applications that don't support encryption themselves) has been to use stunnel or OpenVPN. But those solutions come with a significant performance hit. This article presents measurements and comparisons to illustrate this and presents a more modern solution with much better performance characteristics.

Re: Beyond stunnel: High-speed, secure connections across the public Internet

#4

Post by jbrendel »

wmf wrote: post #3

As usual, someone's pretending that IPSec doesn't exist.

I'm not pretending this. But consider that IPSec doesn't exactly have a reputation for being easy to set up or even is particularly well supported across IaaS provider networks.

People revert to stunnel (and OpenVPN), exactly because they may not have the knowledge or inclination to get a fully featured IPSec setup going.

Re: Beyond stunnel: High-speed, secure connections across the public Internet

#5

Post by pedrocr »

Are the two doing the same amount of encryption or is vCider using a much less complex cipher? Is the CPU difference really just in the kernel vs userspace implementation?

tinc (http://tinc-vpn.org/) would seem like a more interesting comparable than stunnel since it sets up a p2p VPN that routes all IP traffic instead of just a point-to-point link.

Re: Beyond stunnel: High-speed, secure connections across the public Internet

#6

Post by jbrendel »

pedrocr wrote: post #5

Are the two doing the same amount of encryption or is vCider using a much less complex cipher? Is the CPU difference really just in the kernel vs userspace implementation? tinc ( http://tinc-vpn.org/ ) would seem like a more interesting comparable than stunnel since it sets up a p2p VPN that routes all IP traffic instead of just a point-to-point link.

vCider uses AES 256 encryption.

Tinc looks interesting, I will test that as well.

Considering the huge difference in context switches and interrupts, I don't think that encryption induced CPU load is the only issue here.

Kernel stuff on its own doesn't just magically run faster, of course. But in this case, I think it's the constant interaction between user-space and kernel-space, which causes the problem. That's an issue that will impact any user-space solution to a networking problem.

Re: Beyond stunnel: High-speed, secure connections across the public Internet

#7

Post by strags »

One question that isn't in the FAQ that I would instantly be concerned about is exactly what encryption mechanism is used, and where the private keys are stored. Specifically, are they stored in vCider's database?

If my goal was to set up a secure tunnel, I'd be incredibly wary of using a closed source solution like this. Even if you're not worried about the government secretly demanding access to your keys, you might reasonably be concerned about vCider getting hacked.

Re: Beyond stunnel: High-speed, secure connections across the public Internet

#8

Post by pedrocr »

jbrendel wrote: post #6
pedrocr wrote: post #5

Are the two doing the same amount of encryption or is vCider using a much less complex cipher? Is the CPU difference really just in the kernel vs userspace implementation? tinc ( http://tinc-vpn.org/ ) would seem like a more interesting comparable than stunnel since it sets up a p2p VPN that routes all IP traffic instead of just a point-to-point link.

vCider uses AES 256 encryption. Tinc looks interesting, I will test that as well. Considering the huge difference in context switches and interrupts, I don't think that encryption induced CPU load is the only issue here. Kernel stuff on its own doesn't just magically run faster, of course. But in this case, I think it's the constant interaction between user-space and kernel-space, which causes the problem. That's an…

And what encryption is stunnel using? AES was picked to be fast so it may very well be outperforming whatever stunnel uses.

Can 1200 extra context switches and ~6400 extra interrupts per second use up 100% cpu? In fact you mention that for stunnel most of the CPU was in userspace and not the kernel which would indicate time spent actually using the CPU instead of doing context-switches and interrupts, which I assume top would show as "sys".

I also find the extra interrupts strange. I wonder if vCider is sending bigger packets and what caching/latency implications that might have.

Re: Beyond stunnel: High-speed, secure connections across the public Internet

#9

Post by aidenn0 »

pedrocr wrote: post #8
jbrendel wrote: post #6

Earlier quoted context omitted.

vCider uses AES 256 encryption. Tinc looks interesting, I will test that as well. Considering the huge difference in context switches and interrupts, I don't think that encryption induced CPU load is the only issue here. Kernel stuff on its own doesn't just magically run faster, of course. But in this case, I think it's the constant interaction between user-space and kernel-space, which causes the problem. That's an…

And what encryption is stunnel using? AES was picked to be fast so it may very well be outperforming whatever stunnel uses. Can 1200 extra context switches and ~6400 extra interrupts per second use up 100% cpu? In fact you mention that for stunnel most of the CPU was in userspace and not the kernel which would indicate time spent actually using the CPU instead of doing context-switches and interrupts, which I assume…

Also, I had a bitch of a time getting performance out of stunnel, it seemed to ignore hardware acceleration units that openssl was happy to use.

Re: Beyond stunnel: High-speed, secure connections across the public Internet

#10

Post by jbrendel »

pedrocr wrote: post #8
jbrendel wrote: post #6

Earlier quoted context omitted.

vCider uses AES 256 encryption. Tinc looks interesting, I will test that as well. Considering the huge difference in context switches and interrupts, I don't think that encryption induced CPU load is the only issue here. Kernel stuff on its own doesn't just magically run faster, of course. But in this case, I think it's the constant interaction between user-space and kernel-space, which causes the problem. That's an…

And what encryption is stunnel using? AES was picked to be fast so it may very well be outperforming whatever stunnel uses. Can 1200 extra context switches and ~6400 extra interrupts per second use up 100% cpu? In fact you mention that for stunnel most of the CPU was in userspace and not the kernel which would indicate time spent actually using the CPU instead of doing context-switches and interrupts, which I assume…

vCider does not use larger packets. It can't, since they still have to be routed over the same public Internet.

stunnel tries to compress traffic as well, which works if you send a lot of stuff that isn't already compressed. But most of what's sent these days (multi-media?) already is encrypted, so this will be a wasted effort.

Post reply on HN