Bug 3292 - [UPDATE REQUEST] [UPSTREAM UPDATE] openswan
: [UPDATE REQUEST] [UPSTREAM UPDATE] openswan
Status: RESOLVED FIXED
Product: Server Bugs
Classification: ROSA Server
Component: Main Packages
: unspecified
: All Linux
: Normal normal
: ---
Assigned To: Andrew Lukoshko
: ROSA Server Bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-12-02 16:53 MSK by Andrew Lukoshko
Modified: 2014-01-10 10:08 MSK (History)
1 user (show)

See Also:
RPM Package:
ISO-related:
Bad POT generating:
Upstream:
vladimir.potapov: qa_verified+
andrew.lukoshko: published_server+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Lukoshko 2013-12-02 16:53:53 MSK
* Previously, when the IPsec daemon (pluto) attempted to verify the signature of
a Certificate Revocation List (CRL), if the signature value began with a zero
byte and had another zero as padding, the mpz() functions stripped out all
leading zeros. This resulted in the Network Security Services (NSS) data input
being one byte short and consequently failing verification when NSS compared its
length to the modulus length. This update removes the conversions into
arbitrary-precision arithmetic (bignum) objects and handles the leading zero by
moving the pointer one position forward and reducing the length of the signature
by 1. As a result, verification of CRLs now works as expected even with leading
zeros in the signature.

* Previously, the order of the load_crls() and load_authcerts_from_nss()
functions in the plutomain.c file was incorrect. As a consequence, when the
IPsec daemon (pluto) attempted to load the Certificate Revocation Lists (CRLs)
from the /etc/ipsec.d/crls/ directory during startup, loading failed because
pluto checked for a loaded Certification Authority (CA) when there was none
available. This update swaps the order of the aforementioned functions in the
plutomain.c file, and now pluto no longer fails during startup and loads the
CRLs successfully.

* Previously, when the "xauth" option was enabled and the "leftmodecfgclient"
option was disabled in the /etc/ipsec.conf file, the re-key between Openswan and
certain Cisco products, did not work. As a consequence, the Internet Key
Exchange (IKE) tunnel could not be established. This bug has now been fixed and
an IKE tunnel can be successfully established in the described scenario.

* Initial support for passing traffic selectors to an XFRM IPsec stack for
transport mode was incomplete and did not include the necessary work-arounds for
NAT-traversal support. As a consequence, Openswan could not establish an L2TP
connection with devices which use NAT-Traversal. After this update, the
direction of IPsec Security Association (SA) is now passed to the
netlink_setup_sa() function so that the client IP is substituted with the host
IP and the selector works for NAT transport mode.

* Previously, when in FIPS mode, Openswan did not allow the use of SHA2
algorithms. This update enables the use of SHA2 algorithms in FIPS mode.

In addition, this update adds the following enhancements:

* With this update, Openswan now supports Internet Key Exchage (IKE)
fragmentation. Openswan can now successfully connect to devices which support
IKE fragmentation.

* Support for the Internet Key Exchage version 1 (IKEv1) INITIAL-CONTACT IPsec
message, as per RFC2407 Section 4.6.3.3, has been added to Openswan. This
addresses an interoperability issue where a peer does not replace an existing
IPsec Security Association (SA) with a newly negotiated one unless a
Notification Payload message is present.

http://rhn.redhat.com/errata/RHBA-2013-1743.html

https://abf.rosalinux.ru/build_lists/1425941
https://abf.rosalinux.ru/build_lists/1425942
Comment 1 Vladimir Potapov 2013-12-06 13:32:17 MSK
openswan-2.6.32-21.2.res6
**************************** RHEL Advisory ****************************
* Previously, when the IPsec daemon (pluto) attempted to verify the signature of
a Certificate Revocation List (CRL), if the signature value began with a zero
byte and had another zero as padding, the mpz() functions stripped out all
leading zeros. This resulted in the Network Security Services (NSS) data input
being one byte short and consequently failing verification when NSS compared its
length to the modulus length. This update removes the conversions into
arbitrary-precision arithmetic (bignum) objects and handles the leading zero by
moving the pointer one position forward and reducing the length of the signature
by 1. As a result, verification of CRLs now works as expected even with leading
zeros in the signature.

* Previously, the order of the load_crls() and load_authcerts_from_nss()
functions in the plutomain.c file was incorrect. As a consequence, when the
IPsec daemon (pluto) attempted to load the Certificate Revocation Lists (CRLs)
from the /etc/ipsec.d/crls/ directory during startup, loading failed because
pluto checked for a loaded Certification Authority (CA) when there was none
available. This update swaps the order of the aforementioned functions in the
plutomain.c file, and now pluto no longer fails during startup and loads the
CRLs successfully.

* Previously, when the "xauth" option was enabled and the "leftmodecfgclient"
option was disabled in the /etc/ipsec.conf file, the re-key between Openswan and
certain Cisco products, did not work. As a consequence, the Internet Key
Exchange (IKE) tunnel could not be established. This bug has now been fixed and
an IKE tunnel can be successfully established in the described scenario.

* Initial support for passing traffic selectors to an XFRM IPsec stack for
transport mode was incomplete and did not include the necessary work-arounds for
NAT-traversal support. As a consequence, Openswan could not establish an L2TP
connection with devices which use NAT-Traversal. After this update, the
direction of IPsec Security Association (SA) is now passed to the
netlink_setup_sa() function so that the client IP is substituted with the host
IP and the selector works for NAT transport mode.

* Previously, when in FIPS mode, Openswan did not allow the use of SHA2
algorithms. This update enables the use of SHA2 algorithms in FIPS mode.

In addition, this update adds the following enhancements:

* With this update, Openswan now supports Internet Key Exchage (IKE)
fragmentation. Openswan can now successfully connect to devices which support
IKE fragmentation.

* Support for the Internet Key Exchage version 1 (IKEv1) INITIAL-CONTACT IPsec
message, as per RFC2407 Section 4.6.3.3, has been added to Openswan. This
addresses an interoperability issue where a peer does not replace an existing
IPsec Security Association (SA) with a newly negotiated one unless a
Notification Payload message is present.
****************************************************************
QA Verified