[Openswan dev] Openswan patches for better rpm and OCSP support

[Paul Wouters]

On Mon, 5 Dec 2005, Alain RICHARD wrote:

> yes currently some of them are not fully implemented (for example aacerts),
> but they are all references during ipsec startup (you'll gain warning about
> theses not existing during ipsec startup) and they are also references by some
> commands (ipsec auto --listaacerts|--rereadaacerts|--listocspcerts ...). So I
> think it is simpler to just create them.

Agreed.

> In order to get the oscp code being compiled, you need ldap, curl and threads
> support, but also all the oscp code is commented by
> #ifdef HAVE_OCSP instructions, so you need to define HAV_EOCSP in order to get
> oscp support compiled in. The simplest solution
> I have found is to add -DHAVE_OCSP to the X509_DEFS line in
> programs/pluto/Makefile. I have also found a little error in this file where
> X509_DEFS is defined twice. So I have made this little patch :

I will fix this.

> #ifdef HAVE_OCSP code where added when OCSP support was first added. In my
> opinion, it is not needed any longer (and was remove from strongswan for
> example). So an other solution is simply to remove the #ifdef statments :

No. The philosophy of openswan is that functionality can be enabled and
disabled wirh USE_ defines in Makefile.inc. OCSP will not be hardcoded, but
will also be a feature that one can compile in or not.

> > The reason those are not enabled by default is that pluto is not thread
> > safe,
> > and we do not wish to enable threads on pluto when it is not needed.
> > (on a Makefile level, they are not enabled per default also because some
> > embedded
> > Linux machines do not support threading at all)
> >
>
> I well now that openswan is used in other embeded projects, but theses projets
> do not use (as far as I know) the rpm spec file. The rpm spec file is int the
> packaging/redhat folder and is here to build rpm distributions file for
> redhat, fedora and all redhat derived distributions. As far as I know, all
> theses plateforms support LDAP, CURL and THREADS.

Again, pluto is not thread safe, so threads will not be enabled in a default
built. I will fladly have some specfile --define statement that allows building
with USE_OCSP that enabled ldap,curl and threads. It will need to change the
appropriate Requires: line as well.

> I have made some search in the code and found no references to USE_NOCRYPTO
> flag.

You need a newer version of openswan-2 then. It has been recently added.

> Sometimes it is necessary to have access to such functionnalities :
> - 1DES and/or DH1 for compatibility purpose

No. It is completely broken and unsafe, insecure. It equals NOT using crypto.
If you want to use such completely bogus insecure ciphers, you will have to do
work. We will not provide a single happy flag to completely undermine your
security. It is done by design.

> - NULL_ESP for legality reasons (sometimes you are not allowed to use
> cryptography and currently AH is not any longer supported in openswan). An
> other use of NULL_ESP is when you use ipsec uppon an already encrypted layer
> (like Wifi WPA2) and have ipsec harware that do not support full speed
> encryption (Wifi is up to 25 Mbit per seconds currently).

AH and transport mode support was dropped by FreeS/WAN, not Openswan. AH is
not built by default with KLIPS, but you can still enable it and compile it.

I am not sure if I agree with the reasoning. Openswan is an IPsec product,
meant for secure encrypted communicatins. If people want to use it in ways
that are not secure, for instance AH, 1DES, NULL_ESP or DH1, then perhaps they
should not be using an IPsec implementation.

Why would you need AH or ESP_NULL if you trust WPA2?
You do not need ESP_NULL, you can use AH. Using AH makes it obvious there is
no crypto involved, while using ESP_NULL does not. ESP_NULL is only meant for
testing openswan, and not for real world use.

> People needing such weak stuff is always able to enable it by recompilation.

People should not need USE_WEAKSTUFF or USE_NOCRYPTO. Their security is
flawed, broken, compromised. They need to throw away obsolete equiptment,
instead of wading in a false sense of security by using broken or easilly
brute-forcable crypto.

> Perhaps we should add a new ipsec.conf option
> "inowiamsillyusingthisweakstuffbutiwantit=true" ? Or we should completly
> remove this support from the source code ?

It is left it for those who want to do compliance testing for certifications
for various silly governments who want to follow (even obsolete) ciphers in
RFC's. And for those who are aware how bad those ciphers are. People being
told my google to switch idontunderstandthisoptionbutifisetittoyesitworks=yes
and completely breaking the security of their network is not what we wish to
support.

> I do need the CRL and OCSP support and I am proposing to add support for it to
> openswan. Looking at the list, I have also found other people that are needing
> it also.

Okay. If creating patches, please try to follow our guidelines to ensure we can
easilly integrate the patches. This means:
- Proper use of USE_OCSP and #ifdef HAVE_OCSP
- Testcases in testing/ for the nightly regression tests. Without testcases,
  we cannot add the functionality because we cannot test when in the future we
  would break it by accident.

You can sent us patches without testcases, but then we will only integrate it
once we have had the time to write the testcases. You can ask mcr,ken or me on
irc.freenode.net #openswan-dev to help you with setting up the UML testing
infrastructure. (We can give you a script that automates almost everything to
fetch, compile and setup the uml test infrastructure on a development box)

> the README.x509 is very usefull and should probably be included in the default
> openswan rpm package (currently it is only put in the openswan-doc package).

The README.x509 is a big file which we do not want to install per default.

> Also the strongswan projet have a very complete ipsec_auto man page with all
> the options for certificates handling.

The man pages for openswan need updating on various places. This has been
postponed due to a change of the various preprocessors (sgml, docbook, etc).
We realise that it needs to be fixed, and this is listed as a bug entry on
our bugtracker.

Thanks for your work on Openswan. I'll incorporate the changes mentioned
above, and if you need help during the porting of the X.509 patches, feel
free to ask us on the dev mailinglist or on irc at #openswan-dev.

Paul