handle IKE frag used in the first packet. That should not normally happen,
as the initiator does not know yet if the responder can handle IKE frag.
However, in some setups, the first packet is too big to get through, and
assuming the peer supports IKE frag is the only way to go.
racoon should have a setting in the remote section to do taht (something
like ike_frag force)
Since we previously had a release branch and we import here the HEAD of CVS,
let's assume all local changes are to be dumped. Local patches should have
been propagated upstream, anyway.
- Rollback the updates for rsa.h, rsa_eay.c and rsa_err.c as they were
not necessary to address this vulnerability.
- Small update to the patch for rsa_sign.c for backward compatability so
the same patch can be applied to 0.9.[6-9]
Daniel Bleichenbacher recently described an attack on PKCS #1 v1.5
signatures. If an RSA key with exponent 3 is used it may be possible
to forge a PKCS #1 v1.5 signature signed by that key. Implementations
may incorrectly verify the certificate if they are not checking for
excess data in the RSA exponentiation result of the signature.
Since there are CAs using exponent 3 in wide use, and PKCS #1 v1.5 is
used in X.509 certificates, all software that uses OpenSSL to verify
X.509 certificates is potentially vulnerable, as well as any other use
of PKCS #1 v1.5. This includes software that uses OpenSSL for SSL or
TLS.
remove IV support from the CRC attack detector, OpenSSH has never used
it - it only applied to IDEA-CFB, which we don't support.
Thanks to deraadt@OpenBSD for looking into this one.