Project

General

Profile

Bug #854

libipsec support for NULL encryption?

Added by Peter Whisker over 5 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Category:
libipsec
Target version:
Start date:
20.02.2015
Due date:
Estimated time:
Affected version:
5.2.1
Resolution:
Fixed

Description

Hi

We have a requirement for NULL encryption (eg esp=null-sha256-modp4096) - the application needs to ensure integrity but also requires that the content is in the clear. I also need to use libipsec for other reasons relating to kernel separation. I have no problem with the above esp string in standard kernel mode but I get lots of errors if I use it in libipsec mode. Removing the "esp=null-sha256-modp4096" line from ipsec.conf makes libipsec behave but it defaults to AES.

Is it still the case (as per issue 377) that AES and AES-GCM are the only crypto algorithms supported and even NULL encryption does not work with libipsec?

Thanks
Peter

Associated revisions

Revision 4e236a7e (diff)
Added by Tobias Brunner over 5 years ago

openssl: Return the proper IV length for OpenSSL crypters

For instance, the NULL cipher has a block size of 1 but an IV length
of 0.

Fixes #854.

History

#1 Updated by Peter Whisker over 5 years ago

BTW I see the following errors:

Feb 20 11:41:06 IrisP-L-1 charon: 05[ESP] unsupported IP version
Feb 20 11:41:06 IrisP-L-1 charon: 05[ESP] parsing ESP payload failed: unsupported payload

#2 Updated by Tobias Brunner over 5 years ago

Is it still the case (as per issue 377) that AES and AES-GCM are the only crypto algorithms supported and even NULL encryption does not work with libipsec?

As you can see in #377 the limitation to AES/AES-GCM has been lifted with 5.1.1. Since then libipsec supports all the algorithms provided by libstrongswan. And there is a NULL cipher provided by the openssl plugin, otherwise the CHILD_SA negotiation would fail in the first place.

Feb 20 11:41:06 IrisP-L-1 charon: 05[ESP] unsupported IP version
Feb 20 11:41:06 IrisP-L-1 charon: 05[ESP] parsing ESP payload failed: unsupported payload

The problem is that the crypter_t implementation of the openssl plugin always returns the cipher's block size as IV length. While the block size for the NULL cipher is 1 the IV size should be 0. So connections between two instances using libipsec work because they both will send/expect a 1 byte IV, but if one of the peers is implementation that does handle this correctly you'll see the messages above because the ESP packets are parsed with a 1 byte offset (similarly are the sent packets invalid).

While we added more flexibility in regards to the IV length with f7c04c5b37 (before that we always queried the block size externally), using block_size here (source:src/libstrongswan/plugins/openssl/openssl_crypter.c#L135) is incorrect. Actually, the EVP_CIPHER struct has an iv_len member for exactly this purpose. The attached patch fixes the problem.

#3 Updated by Peter Whisker over 5 years ago

Wow! What a quick response. I have patched the code and rebuilt and it works great! Thank you so much!

Peter

#4 Updated by Tobias Brunner over 5 years ago

  • Status changed from Feedback to Closed
  • Resolution set to Fixed

Great, thanks for testing.

Also available in: Atom PDF