| 2015-04-27 06:31:21 |
Richard Laager |
bug |
|
|
added bug |
| 2015-04-27 06:31:21 |
Richard Laager |
attachment added |
|
0001-constraints-Don-t-reject-certificates-with-invalid-c.patch https://bugs.launchpad.net/bugs/1448870/+attachment/4385292/+files/0001-constraints-Don-t-reject-certificates-with-invalid-c.patch |
|
| 2015-04-27 06:32:35 |
Richard Laager |
description |
If a certificate has a policy, strongswan rejects it unless every certificate up the chain has the same policy. For certificates issued by CAs today, this is not a valid assumption. This assumption results in my Ubuntu laptop being unable to connect to my workplace VPN (which is actually also Ubuntu strongswan, but that's irrelevant).
The attached patch from upstream git fixes the problem by changing the validation behavior. From the upstream commit:
Instead of rejecting the certificate completely if a certificate has a policy
OID that is actually not allowed by the issuer CA, we accept it. However, the
certificate policy itself is still considered invalid, and is not returned
in the auth config resulting from trust chain operations.
A user must make sure to rely on the returned auth config certificate policies
instead of the policies contained in the certificate; even if the certificate
is valid, the policy OID itself in the certificate are not to be trusted
anymore. |
If a certificate has a policy, strongswan rejects it unless every certificate up the chain has the same policy. For certificates issued by CAs today, this is not a valid assumption. This assumption results in my Ubuntu laptop being unable to connect to my workplace VPN (which is actually also Ubuntu strongswan, but that's irrelevant).
The attached patch from upstream git fixes the problem by changing the validation behavior. From the upstream commit message:
Instead of rejecting the certificate completely if a certificate has a policy OID that is actually not allowed by the issuer CA, we accept it. However, the certificate policy itself is still considered invalid, and is not returned in the auth config resulting from trust chain operations.
A user must make sure to rely on the returned auth config certificate policies instead of the policies contained in the certificate; even if the certificate is valid, the policy OID itself in the certificate are not to be trusted anymore. |
|
| 2015-04-27 06:37:10 |
Richard Laager |
description |
If a certificate has a policy, strongswan rejects it unless every certificate up the chain has the same policy. For certificates issued by CAs today, this is not a valid assumption. This assumption results in my Ubuntu laptop being unable to connect to my workplace VPN (which is actually also Ubuntu strongswan, but that's irrelevant).
The attached patch from upstream git fixes the problem by changing the validation behavior. From the upstream commit message:
Instead of rejecting the certificate completely if a certificate has a policy OID that is actually not allowed by the issuer CA, we accept it. However, the certificate policy itself is still considered invalid, and is not returned in the auth config resulting from trust chain operations.
A user must make sure to rely on the returned auth config certificate policies instead of the policies contained in the certificate; even if the certificate is valid, the policy OID itself in the certificate are not to be trusted anymore. |
If a certificate has a policy, strongswan rejects it unless every certificate up the chain has the same policy. For certificates issued by CAs today, this is not a valid assumption. This assumption results in my Ubuntu laptop being unable to connect to my workplace VPN (which is actually also Ubuntu strongswan, but that's irrelevant).
The attached patch from upstream git fixes the problem by changing the validation behavior. From the upstream commit message:
--
Instead of rejecting the certificate completely if a certificate has a policy OID that is actually not allowed by the issuer CA, we accept it. However, the certificate policy itself is still considered invalid, and is not returned in the auth config resulting from trust chain operations.
A user must make sure to rely on the returned auth config certificate policies instead of the policies contained in the certificate; even if the certificate is valid, the policy OID itself in the certificate are not to be trusted anymore.
--
This patch applies exactly from upstream to strongswan in Vivid. It can be trivially backported to Precise (which I've done and tested). I did not test any versions in the middle. |
|
| 2015-04-27 06:52:15 |
Richard Laager |
description |
If a certificate has a policy, strongswan rejects it unless every certificate up the chain has the same policy. For certificates issued by CAs today, this is not a valid assumption. This assumption results in my Ubuntu laptop being unable to connect to my workplace VPN (which is actually also Ubuntu strongswan, but that's irrelevant).
The attached patch from upstream git fixes the problem by changing the validation behavior. From the upstream commit message:
--
Instead of rejecting the certificate completely if a certificate has a policy OID that is actually not allowed by the issuer CA, we accept it. However, the certificate policy itself is still considered invalid, and is not returned in the auth config resulting from trust chain operations.
A user must make sure to rely on the returned auth config certificate policies instead of the policies contained in the certificate; even if the certificate is valid, the policy OID itself in the certificate are not to be trusted anymore.
--
This patch applies exactly from upstream to strongswan in Vivid. It can be trivially backported to Precise (which I've done and tested). I did not test any versions in the middle. |
If a certificate has a policy, strongswan rejects it unless every certificate up the chain has the same policy. For certificates issued by CAs today, this is not a valid assumption. This assumption results in my Ubuntu laptop being unable to connect to my workplace VPN (which is actually also Ubuntu strongswan, but that's irrelevant).
The attached patch from upstream git fixes the problem by changing the validation behavior. From the upstream commit message:
--
Instead of rejecting the certificate completely if a certificate has a policy OID that is actually not allowed by the issuer CA, we accept it. However, the certificate policy itself is still considered invalid, and is not returned in the auth config resulting from trust chain operations.
A user must make sure to rely on the returned auth config certificate policies instead of the policies contained in the certificate; even if the certificate is valid, the policy OID itself in the certificate are not to be trusted anymore.
--
This patch applies exactly from upstream to strongswan in Vivid. It can be trivially backported to Precise (which I've done and tested). I did not specifically test it on any versions in the middle. |
|
| 2015-04-27 08:21:46 |
Ubuntu Foundations Team Bug Bot |
tags |
|
patch |
|
| 2015-04-27 08:21:53 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Review Team |
| 2016-02-18 08:42:37 |
Launchpad Janitor |
strongswan (Ubuntu): status |
New |
Fix Released |
|
| 2016-02-18 08:42:37 |
Launchpad Janitor |
bug watch added |
|
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718291 |
|
| 2016-02-18 08:42:37 |
Launchpad Janitor |
cve linked |
|
2014-2338 |
|
| 2016-02-18 08:42:37 |
Launchpad Janitor |
cve linked |
|
2014-9221 |
|
| 2016-02-18 08:42:37 |
Launchpad Janitor |
cve linked |
|
2015-3991 |
|
| 2016-02-18 08:42:37 |
Launchpad Janitor |
cve linked |
|
2015-4171 |
|
| 2016-02-18 08:42:37 |
Launchpad Janitor |
cve linked |
|
2015-8023 |
|
