Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Locked thread
MrMoo
Sep 14, 2000



I'm researching IPsec (Internet Protocol Security) based VPN (Virtual Private Network) tunnels and the realm of security ciphers seems awfully close to the 'sperg-fest of MP3 (MPEG-2 Audio Layer III) bit rates and audiophile wooden volume knobs. The general consensus, if there is any, is that cipher strength needs to increase with time as machines and thus the ability to crack the encryption becomes viable.

Step 1 - The Public Key AlgorithmBlock Cipher for Public-key Cryptosystem

The general standard is AES (Advanced Encryption Standard), Japan went for Camellia (because ), and for software-only dependent folks Blowfish is popular for faster throughput. AES replaces older obsolete ciphers DES (Data Encryption Standard) and 3DES (Triple-DES).

128-bit AES is allegedly safe for "billions of years" (according to the above Wikipedia article), is used by the US government for "SECRET" classified documents, the classification "TOP SECRET" bumps the requirement to 192-bit AES.

Blowfish is allegedly superseded by Twofish and Threefish but are not public-domain.

Step 2 - The Authentication Algorithm

Something about authentication to validate messages, uses a hashing function thus the nomenclature HMAC (Hash Message Authentication Code ), with the common choices of MD5 and SHA-1 considered weak choices. The popular direction appears to be SHA-2 but something called AES-XCBC is available which is a variant of CBC-MAC or the CMAC algorithm submitted to NIST as a standard.

Since 1996 flaws have been found with MD5 thus the start of progression to alternatives. In 2005 a weakness was discovered in SHA-1 and thus SHA-2 was promoted, web browser vendors have set various timelines to declare security certificates using SHA-1 for authentication as insecure.

Step 3 - Diffie-Hellman Parameters

Something about a key agreement protocol. As of 2003 the RSA have claimed weakness for 1024-bit keys and thus 2048-bit key length has been promoted and should remain venerable till 2030.

Step 4 - Hardware Acceleration

Two steps backward, three steps forward (hopefully). Numerous vendors offer flavors of crypto-acceleration that send encrypted bits along faster. Intel has the AES-NI instruction set but requires a modified AES algorithm called AES-GCM (Galois Counter Mode). VIA has an instruction set called Padlock which performs very well with AES-ECB (Electronic Codebook) but is apparently vulnerable and so one should use AES-CBC (Cipher Block Chaining) which just happens to be todays default mode of operation.

Step 5 - Elliptical Curve Cryptography

Given the acronym ECC, curve cryptography usually means one needs fewer bits are needed compared to AES. Controversy arose because the NSA allegedly promoted NIST to use parameters that make the encryption weaker. Out of this grew ciphers such as Curve25519 from noted computer scientist Daniel J. Bernstein.

Step 6 - Real World Implementations

You will see a plethora of hardware vendors such as Cisco along with a limited set of software implementations that are abstracted away with terse translations, predominant being Raccoon (OS X, iOS, pfSense 2.1 and earlier), StrongSWAN (pfSense 2.2), Shrew Soft VPN Client for when Cisco's IPSEC client breaks on Windows. Microsoft also ships an implementation with Windows 7 but without XAUTH support.

Support for Curve25519 is presently in development for StrongSWAN, so unlikely to be in hardware appliances for a while.

Reasonable default cipher set for 2015 appears to be esp=aes128-sha256-modp2048! that is 128-bit AES with HMAC-SHA-2 with 256-bit key and a 2048-bit Diffie-Hellman key.

If you have an Intel AES-NI supported chipset you would use esp=aes128gcm8-aesxcbc-modp2048!, i.e. replacing AES-CBC with AES-GCM, same 128-bit keys but a 64-bit IV (initialization vector), replacing HMAC-SHA-2 with HMAC-AES-XCBC for some reason and the same Diffie-Hellman Group 14 for PFS (Perfect Forward Secrecy).

I cannot find any literature on why would one choose AES-XCBC over SHA-2 though?

MrMoo fucked around with this message at 01:05 on May 12, 2015

Adbot
ADBOT LOVES YOU

Antillie
Mar 14, 2015



Due to how packets are signed in an IPSec tunnel the choice of hash is less important than the choice of encryption algorithm. You can use SHA1 or even MD5 with relative safety as long as you are using AES as an attacker would first have to break the cipher before they could attack the hash. Any serious VPN appliance will have hardware acceleration for AES and when you have hardware acceleration there is very little performance difference between AES-128 and AES-256. So you might as well use AES-256. I don't think I have ever seen anyone use AES-192 in over sever years of working with IPSec,

A 1024 bit Diffie-Hellman exchange is fine. I think you are getting DH confused with 1024 bit RSA keys, which are a bit on the weak side. However people are starting to move to 2048 bit DH exchanges anyway. 3DES and AES are pretty much all you see in the enterprise segment as these ciphers are supported by basically everything. However 3DES is on the way out and AES is becoming the new norm. MD5 isn't used much and SHA1 is very popular. You don't see much SHA2 outside of IKEv2 tunnels, which are somewhat rare. Also, IKEv1 is fine in main mode, IKEv2 just simplifies the exchange sequence and gets rid of the somewhat insecure quick mode.

Also it is very hard to talk about IPSec without talking about phase 1 and phase 2. Both phases generally use the same encryption and hash but this is not strictly required. PFS isn't terribly common in phase 2 but you do see it, usually set to group 2 (1024 bit DH exchange). Then there is the difference between ESP, the defacto standard, and AH, which nobody ever uses because it sucks.

It is worth noting that Cisco has depreciated their IPSec client in favor of AnyConnect and is no longer updating it. If you are on Windows 8 or later you basically can't use it. AnyConnect has an IPSec mode and can operate in IKEv1 or IKEv2 mode but is almost always used as a TLS VPN client since TLS gets past stupid campus/hotel/office/coffee shop firewalls much more often than IPSec. Unfortunately the older ASA firewalls are limited to TLSv1 with TLSv1.2 only being available on the newer ASA-X line as far as I know.

Also AES-NI will accelerate the super common AES-CBC, it just provides even more acceleration for AES-GCM. I want to see what happens when BSD gets support for Intel's quick assist hardware accelerators that are built into some of the the Atom C2000 series CPUs. I think we will see ~27 watt Mini ITX boxes spanking eight core Xeon systems for VPN performance.

I have never heard of AES-XCBC and I don't see any reason to use it when SHA2 is quite secure and supported by basically everything that isn't old. The biggest consideration when setting up an IPSec tunnel is compatibility. Both sides must use the same encryption, hash, and key exchange method in both phases. In my experience the only things you can count on pretty much every random device supporting are 3DES, AES-CBC, MD5, SHA1, and DH groups 1, 2, and 5. However SHA2-256, AES-GCM, and DH group 14 are starting to become more common. But its a lowest common denominator thing. Absolutely every major vendor needs to support something before it can see widespread adoption. And even then it still takes several years for everyone to replace their old crap with new gear.

Antillie fucked around with this message at 00:44 on Apr 17, 2015

MrMoo
Sep 14, 2000



Antillie posted:

A 1024 bit Diffie-Hellman exchange is fine. I think you are getting DH confused with 1024 bit RSA keys, which are a bit on the weak side. However people are starting to move to 2048 bit DH exchanges anyway.

I saw this with OpenVPN, the Easy-RSA package for creating certificates defaults to 1024-bit DH keys and suggests 2048-bit for paranoid people. However it also happens the StrongSWAN examples now seem to prefer 2048-bit keys.

An interesting discussion on DH-key or prime factor generation on Stack Exchange.

Antillie posted:

Also, IKEv1 is fine in main mode, IKEv2 just simplifies the exchange sequence and gets rid of the somewhat insecure quick mode.

The immediate IKEv2 benefits are routing multiple subnets over a single tunnel without an additional XL2TP layer, but also it allows separate secrets per connection which is great if your are only using dumb XAUTH pre-shared keys.

Antillie posted:

Also it is very hard to talk about IPSec without talking about phase 1 and phase 2. Both phases generally use the same encryption and hash but this is not strictly required. PFS isn't terribly common in phase 2 but you do see it, usually set to group 2 (1024 bit DH exchange). Then there is the difference between ESP, the defacto standard, and AH, which nobody ever uses because it sucks.

What appears to be common is that hardware appliances have very restricted phase 1 configurations with phase 2 being more flexible. pfSense despite using StrongSWAN follows common hardware limitations and limits phase 1 to a fixed list of AES, Blowfish, 3DES, CAST128, DES, and HMAC MD5, SHA1, SHA256, SHA384, SHA512, AES-XCBC, but a wide set of DH groups 1-24. Typically with StrongSWAN you can specify a list of ciphers for negotiation of one that both parties agree to.





Antillie posted:

It is worth noting that Cisco has depreciated their IPSec client in favor of AnyConnect and is no longer updating it. If you are on Windows 8 or later you basically can't use it. AnyConnect has an IPSec mode and can operate in IKEv1 or IKEv2 mode but is almost always used as a TLS VPN client since TLS gets past stupid campus/hotel/office/coffee shop firewalls much more often than IPSec. Unfortunately the older ASA firewalls are limited to TLSv1 with TLSv1.2 only being available on the newer ASA-X line as far as I know.

At Reuters we seem to use SSL VPN for client co-location and internal networks whilst IPsec VPN is used for core data networks. Cheap routers or retarded firewalls without IPsec passthrough is obviously the main benefit of moving to SSL. On Windows 7 the two Cisco clients do not like to run together on my Dell craptop so Shrew Soft has been the goto client for IPsec.

Interop is quite the challenge. Windows 7 wants certificates; iOS wants IKEv1 with the user interface, IKEv2 is only available by "enterprise" configuration; pfSense 2.2 had some hard coded parameters like forced MOBIKE which demands matching support on the other side; Chrome OS requires IPsec+LT2P.

So currently I have Windows 7 with Shrew Soft and a simple XAUTH password that needs to be entered every time because the software refuses to save it, apparently XAUTH passwords are just a basic mechanism to indicate the user but does not affect the session encryption; iOS road warrior uses IKEv1 because that is easy; Chrome OS is configured with OpenVPN instead because it works.

code:
# ipsec.conf - strongSwan IPsec configuration file
        
config setup
        cachecrls=yes
        uniqueids=yes
        
# iphone road warrior
conn ios
        keyexchange=ikev1
        authby=xauthpsk
        xauth=server
        left=%defaultroute
        leftsubnet=0.0.0.0/0
        leftid=@atlanta.example.com
        leftfirewall=yes
        right=%any
        rightsubnet=0.0.0.0/0
        rightsourceip=10.36.10.0/24
        rekey=no
        auto=add
        fragmentation=yes
        dpdaction=clear
        dpddelay=5s
        dpdtimeout=20s
For iPhone's and iPad's I set the default route, allow StrongSWAN to manage IP tables for DHCP endpoints, along with enabling fragmentation and tight dead-peer detection parameters for users on varying quality networks and specifically for iOS 8 to reconnect. Rekeying on iOS with XAUTH has been noted problematic but whilst comments that right=%any does not support rekeying but IKEv1 always re-authenticates so rekey=no is probably invalid.

Antillie
Mar 14, 2015



MrMoo posted:

I saw this with OpenVPN, the Easy-RSA package for creating certificates defaults to 1024-bit DH keys and suggests 2048-bit for paranoid people. However it also happens the StrongSWAN examples now seem to prefer 2048-bit keys.

An interesting discussion on DH-key or prime factor generation on Stack Exchange.

Generating RSA keys and certs for use with OpenVPN doesn't really have anything to do with DH exchange as used in the setup of an IPSec tunnel. In the case of generating RSA keys and certs 2048 bits should be the smallest key size used. 1024 bits is just too small for RSA these days. Nobody has figured out a practical way to solve the discrete logarithm problem and until someone does DH will remain secure. However there is certainly nothing wrong with using a larger exchange (1536 bit DH group 5) if you want.

MrMoo posted:

The immediate IKEv2 benefits are routing multiple subnets over a single tunnel without an additional XL2TP layer, but also it allows separate secrets per connection which is great if your are only using dumb XAUTH pre-shared keys.

I send 10+ subnets across IKEv1 IPSec tunnels every day. I have been doing it since 2007. Are you talking about using GRE inside an IPsec tunnel? That's something else entirely. But even then the tunnel only sees the IPs of the GRE endpoints and not actual subnets being routed. You must be using a tunneling method that I am not familiar with.

MrMoo posted:

What appears to be common is that hardware appliances have very restricted phase 1 configurations with phase 2 being more flexible. pfSense despite using StrongSWAN follows common hardware limitations and limits phase 1 to a fixed list of AES, Blowfish, 3DES, CAST128, DES, and HMAC MD5, SHA1, SHA256, SHA384, SHA512, AES-XCBC, but a wide set of DH groups 1-24. Typically with StrongSWAN you can specify a list of ciphers for negotiation of one that both parties agree to.

Every hardware appliance I have ever seen supports the exact same settings in phase 1 and 2. Generally the ones I mentioned as being common. I have never seen an appliance that supported Blowfish, CAST128, or AES-XCBC. In my experience DH groups past group 5 and SHA2 only show up if you use IKEv2.

MrMoo posted:

At Reuters we seem to use SSL VPN for client co-location and internal networks whilst IPsec VPN is used for core data networks. Cheap routers or retarded firewalls without IPsec passthrough is obviously the main benefit of moving to SSL. On Windows 7 the two Cisco clients do not like to run together on my Dell craptop so Shrew Soft has been the goto client for IPsec.

Interop is quite the challenge. Windows 7 wants certificates; iOS wants IKEv1 with the user interface, IKEv2 is only available by "enterprise" configuration; pfSense 2.2 had some hard coded parameters like forced MOBIKE which demands matching support on the other side; Chrome OS requires IPsec+LT2P.

So currently I have Windows 7 with Shrew Soft and a simple XAUTH password that needs to be entered every time because the software refuses to save it, apparently XAUTH passwords are just a basic mechanism to indicate the user but does not affect the session encryption; iOS road warrior uses IKEv1 because that is easy; Chrome OS is configured with OpenVPN instead because it works.

For iPhone's and iPad's I set the default route, allow StrongSWAN to manage IP tables for DHCP endpoints, along with enabling fragmentation and tight dead-peer detection parameters for users on varying quality networks and specifically for iOS 8 to reconnect. Rekeying on iOS with XAUTH has been noted problematic but whilst comments that right=%any does not support rekeying but IKEv1 always re-authenticates so rekey=no is probably invalid.

In my experience interoperability isn't all that hard. For client to site access just pick a VPN solution that has a client for whatever OS's you need to support and install it. Never expect to use a VPN client built into the OS. For site to site just go with AES256 and SHA1 with DH group 5. I went with OpenVPN for my own personal remote access solution. Its very easy to configure and there is a client for pretty much every OS under the sun. And as you mentioned TLS works everywhere and IPSec isn't always allowed out.

code:
dev tun
tun-ipv6
persist-tun
persist-key
cipher AES-256-CBC
auth SHA256
tls-client
client
resolv-retry infinite
remote x.x.x.x 443 tcp-client
lport 0
auth-user-pass
ca my-ca-cert.crt
tls-auth my-tls-key.key 1
ns-cert-type server
comp-lzo adaptive
For business use I always deploy Cisco's AnyConnect client in TLS mode. As it supports Windows, OSX, Linux, Android, and iOS while being an enterprise grade solution with commercial support available from Cisco.

For me IPSec is mostly reserved for site to site tunnels between dedicated hardware appliances.

Antillie fucked around with this message at 00:52 on Apr 17, 2015

Prescription Combs
Apr 20, 2005
   6

Most of my co-workers hate AnyConnect. I love setting it up, it's so easy...

It's always something hurf durf ipsec blah blah old ways. The thing that stinks about it, which I think may be changing, is the licensing. Especially if you want mobile phones to work on Anyconnect you need the 'for mobile' licence.

Antillie
Mar 14, 2015



Yeah the licensing for AnyConnect is a pain in the rear end. But the actual VPN solution is so nice.

MrMoo
Sep 14, 2000



I managed to get IPsec+L2TP working for ChromeOS with the following configuration on StrongSWAN but iOS hates it:
code:
conn chromeos
        keyexchange=ikev1
        type=transport
        authby=psk
        left=%defaultroute
        leftid=@atlanta.example.com
        leftsubnet=%dynamic[udp/l2tp]
        leftfirewall=yes
        right=%any
        rightsubnet=%dynamic[udp/%any]
        auto=add
        fragmentation=yes
        dpdaction=clear
        dpddelay=5s
        dpdtimeout=20s
The logs just yield repeated DPD requests, which is odd as the same settings work fine for vanilla IPsec and iOS. I don't know whether this is a conflict with the XAUTH connection, broken DPD support in iOS IPsec+L2TP or as some weird Google results hint that L2TP should be in a tunnel.

(edit) None of those hypothesis seem correct, additional old client bugs include:

code:
# Using the magic port of "0" means "any one single port". This is
# a work around required for Apple OSX clients that use a randomly
# high port, but propose "0" instead of their port. If this does
# not work, use 17/%any instead.
rightprotoport=17/0
#rightprotoport=17/%any
http://serverfault.com/a/527793/42385

code:
# For updated Windows 2000/XP clients,
# to support old clients as well, use leftprotoport=17/%any
#leftprotoport=17/%any
leftprotoport=17/1701
https://help.ubuntu.com/community/L2TPServer

MrMoo fucked around with this message at 19:07 on Apr 26, 2015

MrMoo
Sep 14, 2000



Antillie posted:

I send 10+ subnets across IKEv1 IPSec tunnels every day. I have been doing it since 2007. Are you talking about using GRE inside an IPsec tunnel? That's something else entirely. But even then the tunnel only sees the IPs of the GRE endpoints and not actual subnets being routed. You must be using a tunneling method that I am not familiar with.

IKEv1 only permits tunneling of a single VLAN unless you are using a proprietary Cisco extension. IKEv2 permits multiple networks in leftsubnet= and rightsubnet= parameters. The typical workaround for this is to use multiple connections or to add L2TP above IPsec, i.e. a level 2 tunneling protocol above a single IPsec connection. On Linux this adds two additional processes I believe - xl2tpd and pppd. You could use GRE or any other IP-in-IP encapsulation protocol but IPsec + L2TP is the standard combination.

ChromeOS only supports OpenVPN or IPsec + L2TP (StrongSwan + xl2tpd).

iOS supports IPsec (Racoon), PPTP (GRE), IPsec + L2TP, and OpenVPN (via a special app). IKEv2 requires usage of Apple's enterprise system prep tool. A lot of the tools are new C++ rewrites by Apple so expect less feature parity and compatibility.

MrMoo fucked around with this message at 19:21 on May 1, 2015

Prescription Combs
Apr 20, 2005
   6

MrMoo posted:

IKEv1 only permits tunneling of a single VLAN unless you are using a proprietary Cisco extension. IKEv2 permits multiple networks in leftsubnet= and rightsubnet= parameters. The typical workaround for this is to use multiple connections or to add L2TP above IPsec, i.e. a level 2 tunneling protocol above a single IPsec connection. On Linux this adds two additional processes I believe - xl2tpd and pppd. You could use GRE or any other IP-in-IP encapsulation protocol but IPsec + L2TP is the standard combination.

ChromeOS only supports OpenVPN or IPsec + L2TP (StrongSwan + xl2tpd).

iOS supports IPsec (Racoon), PPTP (GRE), IPsec + L2TP, and OpenVPN (via a special app). IKEv2 requires usage of Apple's enterprise system prep tool. A lot of the tools are new C++ rewrites by Apple so expect less feature parity and compatibility.

I think you're just used to awful linux IPSec implementations.

Why the hell does strongswan use 'leftsubnet' / 'rightsubnet'? What is the frame of reference? That is confusing as gently caress.

MrMoo
Sep 14, 2000



Here's a hub connection configuration: a site-to-site tunnel with 10.36/16 and 10.208/16 on one side and 10/16, 10.6/16 on the other.
code:
conn kowloon
        keyexchange=ikev2       
        authby=psk
        ike=aes128-sha256-modp2048!
        esp=aes128-sha256-modp2048!
        left=newark.example.com
        leftsubnet=10.36.0.0/16,10.208.0.0/16
        leftid=@newark.example.com  
        leftfirewall=yes
        right=kowloon.example.com
        rightsubnet=10.0.0.0/16,10.6.0.0/16
        rightid=@kowloon.example.com
        auto=route              # on demand
        fragmentation=yes
        compress=no             # unstable
        ikelifetime=3600s
        lifetime=1200s
        mobike=no
        dpdaction=hold
        dpddelay=30s
        dpdtimeout=150s

Antillie
Mar 14, 2015



MrMoo posted:

IKEv1 only permits tunneling of a single VLAN unless you are using a proprietary Cisco extension. IKEv2 permits multiple networks in leftsubnet= and rightsubnet= parameters. The typical workaround for this is to use multiple connections or to add L2TP above IPsec, i.e. a level 2 tunneling protocol above a single IPsec connection. On Linux this adds two additional processes I believe - xl2tpd and pppd. You could use GRE or any other IP-in-IP encapsulation protocol but IPsec + L2TP is the standard combination.

ChromeOS only supports OpenVPN or IPsec + L2TP (StrongSwan + xl2tpd).

iOS supports IPsec (Racoon), PPTP (GRE), IPsec + L2TP, and OpenVPN (via a special app). IKEv2 requires usage of Apple's enterprise system prep tool. A lot of the tools are new C++ rewrites by Apple so expect less feature parity and compatibility.

Not true. I have been tunneling multiple subnets on ASA's, Checkpoints, and Sonicwalls since 2007. I have no idea what you have been using to do IPSec termination, it must be something terrible. Get a real firewall. And no, your Linux box is not a real firewall.

The only devices that have issues with multiple phase 2 SAs for tunneling multiple subnets on a single VPN link are Junipers. Because they have a broken IPSec implementation that does not fully implement the entire RFC. Every other vendor does the job just fine.

Antillie fucked around with this message at 17:23 on May 2, 2015

MrMoo
Sep 14, 2000



Antillie posted:

Not true. I have been tunneling multiple subnets on ASA's, Checkpoints, and Sonicwalls since 2007. I have no idea what you have been using to do IPSec termination, it must be something terrible. Get a real firewall. And no, your Linux box is not a real firewall.

The only devices that have issues with multiple phase 2 SAs for tunneling multiple subnets on a single VPN link are Junipers. Because they have a broken IPSec implementation that does not fully implement the entire RFC. Every other vendor does the job just fine.

Per RFC 4306 it appears the enhancement in IKEv2 is multiple traffic selectors (and narrowing) within a single child SA.

Prescription Combs
Apr 20, 2005
   6

MrMoo posted:

Per RFC 4306 it appears the enhancement in IKEv2 is multiple traffic selectors (and narrowing) within a single child SA.

Ya but you can have multiple SAs to the same peer as long as you aren't using a terrible IPSec implementation device.

MrMoo
Sep 14, 2000



Prescription Combs posted:

Ya but you can have multiple SAs to the same peer as long as you aren't using a terrible IPSec implementation device.

Which comes down to the pros and cons of IKEv1 multiple SAs vs IKEv2 single SA vs GRE/IPsec vs L2TP/IPsec. I don't think I've seen a good break down of these.

Clunky concentrators and VPN servers took 3+ minutes to generate an SA thus the appeal of tunneling, StrongSwan has a default of 9 minutes to start rekeying.

GRE/IPsec by Cisco was followed on with L2F before L2TP appeared. L2TP appears to just wedge in an extra layer between IPsec and PPTP.

For road warriors IKEv2 is more convenient than L2TP/IPsec than IKEv1.

MrMoo
Sep 14, 2000



Windows 7 natively supports IKEv1, IKEv2, and L2TP/IPsec which is quite surprising. To counter that the IKEv1 has a hosed up NAT-T implemented which renders it DoA, by design of course - KB944335. L2TP/IPsec is a waste of time with IKEv2 being available and of course they had to give that a new stupid name - Agile VPN, Cisco are equally dumb and call it FlexVPN, the major advertised benefit being standard MOBIKE support.

What is interesting is that IKEv1 connections can be initiating by the Windows Advanced Firewall on-demand, which is really pretty nifty considering how fast IPsec can be initiated. Of course this feature appears to have been junked with Agile VPN in favour of manual connections, but ahoy Windows 8.1 attempts to revive it in the worst possible manner. Here is an excerpt from that article:

quote:

If you manually disconnect an auto triggered VPN profile, the auto triggering capability gets disabled. To enable auto triggering again, you have to manually check the checkbox in the Networks UI (“Let apps automatically use this VPN connection”) for the connection.

Awesome.

(edit) Windows Server has a feature called Routing and Remote Access that can "dial on demand" for VPN connections, does not help for end users.

The root cause to this conundrum appears to be software patents, VirnetX demanded $400 million from Apple for implementing this feature in iOS.

MrMoo fucked around with this message at 19:52 on May 4, 2015

wolrah
May 8, 2006
what?


Antillie posted:

Also AES-NI will accelerate the super common AES-CBC, it just provides even more acceleration for AES-GCM. I want to see what happens when BSD gets support for Intel's quick assist hardware accelerators that are built into some of the the Atom C2000 series CPUs. I think we will see ~27 watt Mini ITX boxes spanking eight core Xeon systems for VPN performance.

Jim from pfSense was getting 700-900mbit/sec using AES-GCM on a dual core Atom (Lanner FW-7551) a few months back during testing of pfSense 2.2 (FreeBSD 10.1). Far side is an eight core Atom C2758 (Supermicro).
http://www.reddit.com/r/PFSENSE/com...ed_ipsec_in_22/

I wish I had some AES-NI compatible hardware to test it with, but if it can nearly max out gigabit ethernet on a little Atom I'm not sure what tests I could actually do without spending hundreds on 10G cards.

wolrah fucked around with this message at 22:04 on May 4, 2015

Tyren
Dec 28, 2012


Antillie posted:

MD5 isn't used much and SHA1 is very popular. You don't see much SHA2 outside of IKEv2 tunnels, which are somewhat rare.

Side note - MS (and others) plan to deprecate SHA1 very soon (circa 2016). While we don't see SHA2 often, I'm guessing we'll see more alternatives to SHA1 in the near future.

https://www.schneier.com/blog/archi...soft_retir.html

Prescription Combs
Apr 20, 2005
   6

Tyren posted:

Side note - MS (and others) plan to deprecate SHA1 very soon (circa 2016). While we don't see SHA2 often, I'm guessing we'll see more alternatives to SHA1 in the near future.

https://www.schneier.com/blog/archi...soft_retir.html


SHA1 has pretty much been deprecated by the popular browsers. Most certs have been re-keyed with SHA256.

Edit: I'm legitimately excited to see software solutions starting to utilize the AES/AES-NI extensions

Prescription Combs fucked around with this message at 00:22 on May 5, 2015

Antillie
Mar 14, 2015



MrMoo posted:

Per RFC 4306 it appears the enhancement in IKEv2 is multiple traffic selectors (and narrowing) within a single child SA.

IKEv1 does the same thing with multiple SAs. No real difference in functionality or how you configure the tunnel. Its a non feature in IKEv2. However the elimination of the somewhat insecure quick mode in IKEv2 is nice.

Antillie
Mar 14, 2015



MrMoo posted:

Which comes down to the pros and cons of IKEv1 multiple SAs vs IKEv2 single SA vs GRE/IPsec vs L2TP/IPsec. I don't think I've seen a good break down of these.

Clunky concentrators and VPN servers took 3+ minutes to generate an SA thus the appeal of tunneling, StrongSwan has a default of 9 minutes to start rekeying.

GRE/IPsec by Cisco was followed on with L2F before L2TP appeared. L2TP appears to just wedge in an extra layer between IPsec and PPTP.

For road warriors IKEv2 is more convenient than L2TP/IPsec than IKEv1.

What the gently caress kind of VPN device are you using if it can't generate an SA in under 2 seconds? Heck any non terrible device will build the entire tunnel, phase 1 and 2, in under 2 seconds.

I would say that GRE/IPsec stands out as by far the easiest way to use a dynamic routing protocol over a VPN link. That way you don't need to mess with the encryption domain if OSPF suddenly decides to start sending traffic for a new subnet over the tunnel. L2TP/IPsec is generally a pain to configure but this depends on the platform. There is no real difference between IKEv1 multiple SAs and IKEv2 single SA for tunneling multiple subnets. However IKEv2 tunnels usually allow SHA2 and larger DH groups depending on the device in question. IKEv2 also gets rid of quick mode but nobody should be using that in IKEv1 anyway.

For road warriors IKEv2 offers no real advantage over IKEv1. However a TLS tunnel is far better than IPSec in my experience in that situation.

Antillie fucked around with this message at 14:25 on May 5, 2015

Antillie
Mar 14, 2015



Tyren posted:

Side note - MS (and others) plan to deprecate SHA1 very soon (circa 2016). While we don't see SHA2 often, I'm guessing we'll see more alternatives to SHA1 in the near future.

https://www.schneier.com/blog/archi...soft_retir.html

That really only applies to SSL\TLS where SHA1 does have some issues. In IPSec SHA1 is still fine due to the vast differences in the basic structure of the protocol.

MrMoo
Sep 14, 2000



Antillie posted:

What the gently caress kind of VPN device are you using if it can't generate an SA in under 2 seconds? Heck any non terrible device will build the entire tunnel, phase 1 and 2, in under 2 seconds.

I believe I am misinterpreting the description of "margintime" which is described as "how long before connection expiry or keying-channel expiry should attempts to negotiate a replacement begin", and is used as a window to randomly select a time to rekey to "avoid collisions". What are the collisions referring to? Each endpoint proposing a new SA at the same time?

MrMoo
Sep 14, 2000



Sophos has been a major sponsor of StrongSwan and uses it in their UTM appliances. pfSense 2.2 replaced Racoon with StrongSWAN and their last version has broken multiple-SA IKEv1 support.

ChromeOS ships with StrongSwan.

OS X ships with Racoon and Apple appears to be undecided how to support IKEv2, iOS has presumably a bespoke implementation with no UI.

So F/OSS world has a plethora of IPsec implementations here is history of From FreeS/WAN to Openswan (2003 - 2011)

quote:

Commercial companies were using freeswan as one of their key interoperability tests during "bake off" events. Andreas Steffen wrote a large patch to add X.509 support to freeswan, something that Gilmore refused to merge in. NAT-Traversal support written by Mathieu Lafon was another essential feature needed for commercial VPN support that Gilmore refused to let into the freeswan code. One of the freeswan volunteers, Ken Bantoft, maintained a version of freeswan with these patches merged in, and called it "super-freeswan". Gilmore was not happy with the use of the name "freeswan" as he did not want those internet crippling technologies associated with the freeswan name.

MrMoo fucked around with this message at 17:19 on May 5, 2015

Antillie
Mar 14, 2015



wolrah posted:

Jim from pfSense was getting 700-900mbit/sec using AES-GCM on a dual core Atom (Lanner FW-7551) a few months back during testing of pfSense 2.2 (FreeBSD 10.1). Far side is an eight core Atom C2758 (Supermicro).
http://www.reddit.com/r/PFSENSE/com...ed_ipsec_in_22/

I wish I had some AES-NI compatible hardware to test it with, but if it can nearly max out gigabit ethernet on a little Atom I'm not sure what tests I could actually do without spending hundreds on 10G cards.

Not much really. The C2758 is a full gigabit wire speed device for IPSec, routing, and firewalling/NAT all at the same time. In fact it has plenty of power to spare for other things like Snort or Squid depending on how much ram and drive space you give it. I suppose you could try to get a full 4 gbps out of it if you have a version with a quad Intel gigabit adapter built in but I don't think that would cap it out on its own. It may not be able to handle full 10 gbps but it probably comes close.

I have a pfSense box at home built on that board and I lack the hardware to properly benchmark it myself. But my god does it scream for what I do use it for.

Antillie fucked around with this message at 17:57 on May 5, 2015

Tyren
Dec 28, 2012


Saw this on netsec the other day. For all those who've yet to see it:

How to make two binaries with the same MD5 hash
http://natmchugh.blogspot.com/2015/...h-same-md5.html

Antillie
Mar 14, 2015



Tyren posted:

Saw this on netsec the other day. For all those who've yet to see it:

How to make two binaries with the same MD5 hash
http://natmchugh.blogspot.com/2015/...h-same-md5.html

That's been around for a long time now. At least 6 or 7 years I think. MD5 by itself is horribly broken and using it in SSL/TLS is a very bad idea. In IPSec its less of an issue due the way that IPSec signs packets. However SHA1 is still better and should be used instead anyway.

inignot
Aug 31, 2003

WWBCD?

SHA2 is available for IPSec on Cisco routers currently.

MrMoo
Sep 14, 2000



A longstanding defect with the Cisco IPsec VPN client in iOS is quite interesting, SA rekeying in the clients occurs after 60 minutes but fails to do something properly and disconnects. StrongSwan's commentary on the piece is hilarious blaming pretty much anything. Apparently OS X had the same problem but was fixed in Yosemite. So the StrongSwan team developed an odd hack just for iOS called xauth-noauth that bypasses XAUTH authentication and sends a success response, I wonder what other vendors do?
code:
conn ioscert
        keyexchange=ikev1
        left=%defaultroute
        leftsubnet=0.0.0.0/0
        leftid=@newark.example.com
        leftauth=pubkey
        leftcert=servercert.der
        leftfirewall=yes
        right=%any
        rightsubnet=0.0.0.0/0
        rightsourceip=10.36.15.0/24
        rightauth=pubkey
        rightauth2=xauth-noauth
        auto=add
        fragmentation=yes
        compress=no
        dpdaction=clear
        dpddelay=5s
        dpdtimeout=20s
here's the rekeying time point in Racoon logs on OS X:
code:
Aug 20 10:00:34 MBP racoon[38259]: IPSec Phase1 started (Initiated by me).
Aug 20 10:00:34 MBP racoon[38259]: IKE Packet: transmit success. (Initiator, Aggressive-Mode message 1).
Aug 20 10:00:34 MBP racoon[38259]: IKEv1 Phase1 AUTH: success. (Initiator, Aggressive-Mode Message 2).
Aug 20 10:00:34 MBP racoon[38259]: IKE Packet: receive success. (Initiator, Aggressive-Mode message 2).
Aug 20 10:00:34 MBP racoon[38259]: IKEv1 Phase1 Initiator: success. (Initiator, Aggressive-Mode).
Aug 20 10:00:34 MBP racoon[38259]: IKE Packet: transmit success. (Initiator, Aggressive-Mode message 3).
Aug 20 10:00:34 MBP racoon[38259]: IPSec Phase1 established (Initiated by me).
Aug 20 10:00:34 MBP racoon[38259]: IKE Packet: receive success. (Information message).
Aug 20 10:00:34 MBP racoon[38259]: IPSec Extended Authentication requested.
Aug 20 10:00:34 MBP configd[16]: IPSec requesting Extended Authentication.
Aug 20 10:00:34 MBP configd[16]: IPSec Controller: XAuth reauthentication dialog required, so connection aborted
Aug 20 10:00:34 MBP configd[16]: IPSec disconnecting from server xx.xx.xx.xx
Aug 20 10:00:34 MBP racoon[38259]: IPSec disconnecting from server xx.xx.xx.xx
Aug 20 10:00:34 MBP racoon[38259]: IKE Packet: transmit success. (Information message).
Aug 20 10:00:34 MBP racoon[38259]: IKEv1 Information-Notice: transmit success. (Delete IPSEC-SA).
Aug 20 10:00:34 MBP racoon[38259]: IKE Packet: transmit success. (Information message).
Aug 20 10:00:34 MBP racoon[38259]: IKEv1 Information-Notice: transmit success. (Delete ISAKMP-SA).
Bug id #11871577 from way back in 2012 it seems.

MrMoo fucked around with this message at 00:35 on May 11, 2015

Antillie
Mar 14, 2015



For better or worse Cisco has abandoned IPSec as a remote access solution. They have been pushing AnyConnect exclusively for several years now. They see IPSec as a site to site tunneling method only these days. I don't really see any point in bothering to fix that bug. All VPN clients that come built into OSs are terrible and should not be used anyway. Although the Cisco IPSec client built into OSX and iOS is one of the better ones, if you are using an actual Cisco device on the other end of the tunnel that is.

Cisco is supposed to reworking how they do AnyConnect licensing to make it less annoying. I really look forward to that, because AnyConnect really is a great solution for my customers in every case.

Antillie fucked around with this message at 15:08 on May 11, 2015

MrMoo
Sep 14, 2000



OpenVPN-AS is pretty slick as an alternative but the future could be IPsec configured like DIrectAccess which is rather smart, bypass all the clunky pieces.

spankmeister
Jun 15, 2008








couple of points:

1. SHA-1 is considered insecure for certificate signing but at the moment is still safe for message signing. This is because an SSL certificate with SHA-1 is fairly static (used between 1 to 3 or even up to 10 years ) so you have lots of time to find a collision. This is not the case with signing packets, which are by nature very short lived.
So SHA-1 is fine, for now....

2. DH key are slightly harder to crack than RSA keys due to discrete log being harder than factoring primes but honestly it's very little difference so 1024 bit parameters are definitely not safe. Use 2048 or higher. (I use 3072 as a good balance between security and performance).

3. Nitpicking but AES, DES, blowfish etc are not public key algorithms, but block ciphers. RSA, DH and ECDH are public key algorithms.

MrMoo
Sep 14, 2000



I found this article AES256-CBC vs AES256-CTR in SSH which was interesting as it shows SSH prefers AES CTR (Counter) mode by default, if following OpenSSH's manpage:

quote:

Ciphers
Specifies the ciphers allowed for protocol version 2 in order of preference. Multiple
ciphers must be comma-separated.

The default is:

aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
aes128-gcm@openssh.com,aes256-gcm@openssh.com,
chacha20-poly1305@openssh.com,
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
aes256-cbc,arcfour
The benefits being lower latency and cons being a significant weakness for data reusing the same IV, so it depends on whether IPsec resets from the same starting point for each connection.

Random testing on an E5-2680:
code:
type                 16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc        467308.07k   519446.61k   539072.85k   542258.86k   543350.78k
aes-128-ctr        372502.28k  1076462.27k  1883048.79k  2410511.36k  2672528.04k
aes-128-gcm        241830.67k   583661.95k   765165.91k   840589.65k   837268.82k
camellia-128-cbc    71470.59k   109661.25k   127749.63k   134138.54k   135187.11k
I guess if you are CPU bound on IPsec.

MrMoo fucked around with this message at 02:29 on May 12, 2015

Prescription Combs
Apr 20, 2005
   6

Are those numbers packets per second? If so that's fast as hell.

Edit: Oh I see, openSSL 'speed' benchmarks.


On my i5-2500K

code:
OpenSSL> speed -evp aes-128-cbc aes-256-cbc camellia-128-cbc
Doing aes-256 cbc for 3s on 16 size blocks: 17380960 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 64 size blocks: 4710371 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 256 size blocks: 1191494 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 1024 size blocks: 299249 aes-256 cbc's in 3.00s
Doing aes-256 cbc for 3s on 8192 size blocks: 37441 aes-256 cbc's in 3.00s
Doing camellia-128 cbc for 3s on 16 size blocks: 22247823 camellia-128 cbc's in 3.00s
Doing camellia-128 cbc for 3s on 64 size blocks: 8415460 camellia-128 cbc's in 3.00s
Doing camellia-128 cbc for 3s on 256 size blocks: 2383579 camellia-128 cbc's in 3.00s
Doing camellia-128 cbc for 3s on 1024 size blocks: 615498 camellia-128 cbc's in 3.00s
Doing camellia-128 cbc for 3s on 8192 size blocks: 77781 camellia-128 cbc's in 2.99s
Doing aes-128-cbc for 3s on 16 size blocks: 146106823 aes-128-cbc's in 2.99s
Doing aes-128-cbc for 3s on 64 size blocks: 38846021 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 9868240 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 2477179 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 309895 aes-128-cbc's in 3.00s
OpenSSL 1.0.1k-fips 8 Jan 2015
built on: Thu Mar 19 17:34:17 2015

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256 cbc      92698.45k   100487.91k   101674.15k   102143.66k   102238.89k
camellia-128 cbc   118655.06k   179529.81k   203398.74k   210089.98k   213104.33k
aes-128-cbc     781842.53k   828715.11k   842089.81k   845543.77k   846219.95k

Neat.

Prescription Combs fucked around with this message at 03:27 on May 12, 2015

Antillie
Mar 14, 2015



spankmeister posted:

2. DH key are slightly harder to crack than RSA keys due to discrete log being harder than factoring primes but honestly it's very little difference so 1024 bit parameters are definitely not safe. Use 2048 or higher. (I use 3072 as a good balance between security and performance).

To quote people who understand this much better than I do:

quote:

A summary of all this goes thus: while 1024-bit DH is somewhat stronger (theoretically) than 1024-bit RSA, the difference is slight (say, 1024-bit DH is like 1200-bit RSA at most). But in practical terms the risk of private key theft, for a non-ephemeral key, dwarfs out any cryptanalytic risk for any RSA or DH of 1024 bits or more; in that sense, PFS is a must-have and DHE with a 1024-bit DH key is much safer than RSA-based cipher suites, regardless of the RSA key size.

Basically 1024 bit DH is fine because you only use each key once while RSA keys are used for years.

I suppose if you are worried about someone recording your IPSec session and then spending several years trying to break it then 1024 bit DH is a bit weak. However if you are running PFS then they will need to break each exchange. Even then getting the time to break each exchange in years down to the single digits is going to require someone with the resources of a state actor like the NSA. Most bad guys aren't anywhere near this level of capability. It really depends on how long you need to protect the data for and how determined the attacker is.

The real risk is someone stealing the private key though other means, which doesn't apply to DH. This has happened to a few CA's over the years and has resulted in "valid" certificates being issued to the attackers for domains that they did not actually own.

Personally I use 1536 bit DH exchange most of the time just to be safe since it is compatible with more devices than a 2048 bit exchange. However if both peer devices support 2048 bit DH exchange there is really no reason not to use it.

Antillie fucked around with this message at 14:49 on May 12, 2015

Adbot
ADBOT LOVES YOU

MrMoo
Sep 14, 2000



Don't put weak ciphers in your negotiation list children, how is this not bleedingly obvious?

https://weakdh.org - The Logjam Attack

  • Locked thread