|
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 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 02:05 on May 12, 2015 |
#
?
Apr 15, 2015 20:31
|
|
|
|
| # ? Apr 23, 2024 19:40 |
|
|
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 01:44 on Apr 17, 2015 |
|
#
?
Apr 16, 2015 02:47
|
|
|
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:
|
|
#
?
Apr 16, 2015 15:39
|
|
|
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. 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. 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:For me IPSec is mostly reserved for site to site tunnels between dedicated hardware appliances. Antillie fucked around with this message at 01:52 on Apr 17, 2015 |
|
#
?
Apr 16, 2015 19:24
|
|
|
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.
|
|
#
?
Apr 17, 2015 22:15
|
|
|
Yeah the licensing for AnyConnect is a pain in the rear end. But the actual VPN solution is so nice.
|
|
#
?
Apr 18, 2015 02:04
|
|
|
I managed to get IPsec+L2TP working for ChromeOS with the following configuration on StrongSWAN but iOS hates it:code:(edit) None of those hypothesis seem correct, additional old client bugs include: code:code:MrMoo fucked around with this message at 20:07 on Apr 26, 2015 |
|
#
?
Apr 26, 2015 19:43
|
|
|
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 20:21 on May 1, 2015 |
|
#
?
May 1, 2015 20:14
|
|
|
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. 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.
|
|
#
?
May 2, 2015 07:51
|
|
|
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:
|
|
#
?
May 2, 2015 15:08
|
|
|
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. 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 18:23 on May 2, 2015 |
|
#
?
May 2, 2015 18:09
|
|
|
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. Per RFC 4306 it appears the enhancement in IKEv2 is multiple traffic selectors (and narrowing) within a single child SA.
|
|
#
?
May 2, 2015 20:48
|
|
|
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.
|
|
#
?
May 3, 2015 05:55
|
|
|
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.
|
|
#
?
May 3, 2015 16:36
|
|
|
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 20:52 on May 4, 2015 |
|
#
?
May 4, 2015 20:24
|
|
|
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/comments/2gpckc/pfsense_aesni_accelerated_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 23:04 on May 4, 2015 |
|
#
?
May 4, 2015 23:00
|
|
|
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/archives/2013/11/microsoft_retir.html
|
|
#
?
May 5, 2015 00:16
|
|
|
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. 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 01:22 on May 5, 2015 |
|
#
?
May 5, 2015 01:18
|
|
|
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.
|
|
#
?
May 5, 2015 15:13
|
|
|
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. 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 15:25 on May 5, 2015 |
|
#
?
May 5, 2015 15:17
|
|
|
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. 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.
|
|
#
?
May 5, 2015 15:18
|
|
|
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?
|
|
#
?
May 5, 2015 17:41
|
|
|
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 18:19 on May 5, 2015 |
|
#
?
May 5, 2015 18:05
|
|
|
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). 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 18:57 on May 5, 2015 |
|
#
?
May 5, 2015 18:55
|
|
|
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/05/how-to-make-two-binaries-with-same-md5.html
|
|
#
?
May 8, 2015 02:06
|
|
|
Tyren posted:Saw this on netsec the other day. For all those who've yet to see it: 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.
|
|
#
?
May 8, 2015 23:37
|
|
|
SHA2 is available for IPSec on Cisco routers currently.
|
|
#
?
May 9, 2015 16:01
|
|
|
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:code:MrMoo fucked around with this message at 01:35 on May 11, 2015 |
|
#
?
May 10, 2015 16:54
|
|
|
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 16:08 on May 11, 2015 |
|
#
?
May 11, 2015 16:04
|
|
|
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.
|
|
#
?
May 11, 2015 17:16
|
|
|
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.
|
|
#
?
May 12, 2015 00:21
|
|
|
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 Random testing on an E5-2680: code:MrMoo fucked around with this message at 03:29 on May 12, 2015 |
|
#
?
May 12, 2015 02:43
|
|
|
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:Prescription Combs fucked around with this message at 04:27 on May 12, 2015 |
|
#
?
May 12, 2015 03:57
|
|
|
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 15:49 on May 12, 2015 |
|
#
?
May 12, 2015 15:35
|
|
|
|
| # ? Apr 23, 2024 19:40 |
|
|
Don't put weak ciphers in your negotiation list children, how is this not bleedingly obvious? https://weakdh.org - The Logjam Attack
|
|
#
?
May 20, 2015 16:38
|
|