[Openswan dev] Openswan patches for better rpm and OCSP support
Alain RICHARD
alain.richard at equation.fr
Mon Dec 5 10:11:18 CET 2005
Le 4 déc. 05 à 10:00, Paul Wouters a écrit :
> On Fri, 2 Dec 2005, Alain RICHARD wrote:
>
>> I have submitted a bug report and the corresponding patch report
>> for some
>> issues in openswan 2.4.4.
>
> Thank you. I noticed the bug report, and I do intend to fix some of
> the issues
> you reported.
>
>> - the rpm spec file is missing folders needed for x509 support
>> (/etc/ipsec.d/{aacerts,cacerts,certs,crls,ocspcerts,private})
>
> Not all of those are supported by the X.509 patch that is included
> in openswan,
> but you are right that we could create those directories.
>
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.
>> - OCSP support is not correctly built because pluto makefile is
>> missing some
>> definitions
>
> You mean the ones listed below? ldap, curl and threads? Or is there
> more?
>
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 :
--- openswan-2.4.4.orig/programs/pluto/Makefile 2005-08-12
03:12:38.000000000 +0200
+++ openswan-2.4.4/programs/pluto/Makefile 2005-11-29
11:11:21.000000000 +0100
@@ -150,8 +150,7 @@
SMARTCARD_DIST_SRCS=smartcard.c smartcard.h
X509_OBJS=${X509_DIST_OBJS}
X509_SRCS=${X509_DIST_SRCS}
-X509_DEFS=-DX509
-X509_DEFS=-DX509_VERSION=\"${X509_VERSION}\"
+X509_DEFS=-DX509_VERSION=\"${X509_VERSION}\" -DHAVE_OCSP
#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 :
macagr:~/Desktop/openswan-2.4.5dr3 arichard$ find . -type f | xargs
grep HAVE_OCSP
./programs/pluto/plutomain.c:#ifdef HAVE_OCSP
./programs/pluto/rcv_whack.c:#ifdef HAVE_OCSP
./programs/pluto/rcv_whack.c:#ifdef HAVE_OCSP
>> - the rpm spec file do not ask for LDAP, CURL and THREADS support
>> that are
>> needed for OCSP support. As the Redhat and Fedora projects
>> addressed by this
>> spec file do support all theses three functionalities, I have
>> enabled them per
>> default.
>
> 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.
Also note that THREAD support is only used during the fetching of
OCSP certs and CRL. And there are only used if you enable it in the
config file (using ipsec.conf crlcheckinterval). So I propose to
enable it on the spec file only, like the patch submitted.
>> - openswan may be built with some weak stuff (as far as security
>> is concerned)
>> : DH group 1, Single DES and Null ESP encryption. Per default theses
>> functionnalities are not built, but there is a flag
>> (USE_WEAKSTUFF) that
>> currently enables DH1 and you may add #defines to built the other two
>> functionnalities. I propose that USE_WEAKSTUFF cover also the
>> built of 1DES
>> and NULL_ESP.
>
> 1DES and NULL_ESP is not weak, it is not real. It is further
> enabled by setting
> the USE_NOCRYPTO flags to signify that you know you are running
> with "no
> cryptography". We firmly believe 1DES to be equal to "no
> cryptography".
> Therefor we do wish to make such false security easilly available
> to people.
>
>> - per default the rpm spec file do not enables the WEAKSTUFF. I
>> have added a
>> define that enables to build a rpm with the WEAKSTUFF enabled
>> using "rpmbuild
>> -ta --define useweakstuff=true openswan-xxx.tar.gz". This do not
>> change the
>> fact that openswan per default do not support theses weak stuff,
>> but enables
>> persons who need them (and there are cases where this is really
>> needed) to use
>> them (and in fact this is already possible as the source code
>> support it).
>
> We prefer to not encourage the use of either DH1 or 1DES. Every day
> that passes,
> they become even weaker. Especially people who will use recompiled
> rpms with
> this, thereby being large deployers of this need, should really
> migrate their
> systems to add real crypto. I will talk with the other developers,
> but I don't
> think we will want to facilitate easy access to these options.
>
I have made some search in the code and found no references to
USE_NOCRYPTO flag.
Sometimes it is necessary to have access to such functionnalities :
- 1DES and/or DH1 for compatibility purpose
- 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).
I do understand that you don't want this to be enabled per default in
openswan, but the code currently support it and there is a lot of
extra warning issued during negociation of such functionnalities.
People needing such weak stuff is always able to enable it by
recompilation. They just spent some time to found how to do it in
openswan (and writing on the various support lists).
Perhaps we should add a new ipsec.conf option
"inowiamsillyusingthisweakstuffbutiwantit=true" ? Or we should
completly remove this support from the source code ?
>> I have also looked at the OCSP support and it seams that it is not
>> completly
>> working yet. This code is old and have some bugs that where
>> corrected in the
>> strongswan project.
>>
>> I am investigating theses problems and I would like to know if
>> there is any
>> particular reasons for openswan beeing not more in sync with the
>> strongswan
>> project ?
>
> We did not have the resources for pulling up the X.509 changes made
> by Andreas.
>
>> Is somebody working in merging more strongswan functionnalities
>> (like CRL caching and CA Management) ?
>
> Not at this point. If someone has an intested in this, please
> contact me off list.
> Ofcourse, anyone is welcome to submit patches for this.
>
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.
>> Also the documentation of the
>> StrongSwan project is more complete than the one in openswan, is
>> there any
>> reasons not to include it ?
>
> I have not looked at the changes. README.x509 is included with
> Openswan. I have
> not read the updates to Andreas his documentation. Some of it does
> not apply due
> to code changes. For example Openswan always uses strict mode,
> where Andreas is
> using the !-symbol to denote strict mode. There might be other
> changes. So it
> is not just a 'download and put in openswan-2/doc/ issue.
>
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). Also the strongswan projet have a very
complete ipsec_auto man page with all the options for certificates
handling.
>> If there is nobody working on it and if Andreas is OK, I may spent
>> some time
>> to port more stuff from Andreas' project to openswan.
>
> Sure, we'd welcome patches.
>
> Paul
If Andreas is agree, I will submet some patches.
Regards,
--
Alain RICHARD <mailto:alain.richard at equation.fr>
EQUATION SA <http://www.equation.fr/>
Tel : +33 477 79 48 00 Fax : +33 477 79 48 01
Applications client/serveur, ingénierie réseau et Linux
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/dev/attachments/20051205/013e1ec0/attachment-0001.htm
More information about the Dev
mailing list