| Message ID | alpine.DEB.2.02.1402150018560.43540@department-of-alchemy.MIT.EDU |
|---|---|
| State | Superseded |
| Headers | show |
On Sat, Feb 15, 2014 at 12:21:32AM -0500, Anders Kaseorg wrote: > Commit 51e3eafb68e15e78e98ca955704be8a6c3a7b304 was too strict in > forbidding certificates marked for client use. For example, this > broke the MIT SECURE wireless network. The extended key usage is a > _list_ of allowed uses, and rather than checking that client use is > not in the list, we should check that server use is in the list. This is unfortunate.. This check was added based on an explicit specification requirement on the server certificate being rejected if it contains id-kp-clientAuth and as such, that commit was actually following that requirement on purpose in the way that would trigger based on any entry matching. I understand the view that this should not break (reasonably) deployed existing networks and this may require some reconsideration. However, I don't think that this change to require id-kp-serverAuth to be present would be good either since it would likely break even more use cases. It might be more reasonable to reject the server based on id-kp-clientAuth being present without id-kp-serverAuth. Would it be possible to get the MIT SECURE server certificate that hits this new constraint on id-kp-clientAuth being present? This would be useful for further discussion on possible spec changes/clarifications.
On 02/15/2014 02:48 AM, Jouni Malinen wrote: > On Sat, Feb 15, 2014 at 12:21:32AM -0500, Anders Kaseorg wrote: >> Commit 51e3eafb68e15e78e98ca955704be8a6c3a7b304 was too strict in >> forbidding certificates marked for client use. For example, this >> broke the MIT SECURE wireless network. The extended key usage is a >> _list_ of allowed uses, and rather than checking that client use is >> not in the list, we should check that server use is in the list. > > This is unfortunate.. This check was added based on an explicit > specification requirement on the server certificate being rejected if > it contains id-kp-clientAuth and as such, that commit was actually > following that requirement on purpose in the way that would trigger > based on any entry matching. I’m not seeing that specification requirement. I looked at EAP-TLS (RFC 5216): Implementations SHOULD use the Extended Key Usage (see Section 4.2.1.13 of [RFC3280]) extension and ensure that at least one of the following is true: 1) The certificate issuer included no Extended Key Usage identifiers in the certificate. 2) The issuer included the anyExtendedKeyUsage identifier in the certificate (see Section 4.2.1.13 of [RFC3280]). 3) The issuer included the id-kp-serverAuth identifier in the certificate (see Section 4.2.1.13 [RFC3280]). and EAP-TTLS (RFC 5281): Clients and servers should implement policies related to the Extended Key Usage (EKU) extension [RFC5280] of certificates it receives, to ensure that the other party's certificate usage conforms to the certificate's purpose. Typically, a client EKU, when present, would be expected to include id-kp-clientAuth; a server EKU, when present, would be expected to include id-kp-serverAuth. Note that absence of the EKU extension or a value of anyExtendedKeyUsage implies absence of constraint on the certificate's purpose. and the specification of id-ce-extKeyUsage itself (RFC 5280): If the extension is present, then the certificate MUST only be used for one of the purposes indicated. If multiple purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present. Certificate using applications MAY require that the extended key usage extension be present and that a particular purpose be indicated in order for the certificate to be acceptable to that application. If a CA includes extended key usages to satisfy such applications, but does not wish to restrict usages of the key, the CA can include the special KeyPurposeId anyExtendedKeyUsage in addition to the particular key purposes required by the applications. Conforming CAs SHOULD NOT mark this extension as critical if the anyExtendedKeyUsage KeyPurposeId is present. Applications that require the presence of a particular purpose MAY reject certificates that include the anyExtendedKeyUsage OID but not the particular OID expected for the application. This is all about requiring certain key usage values to be included; there’s nothing about requiring other values to be excluded. Admittedly, I should fix the patch to accept anyExtendedKeyUsage (XKU_ANYEKU) as well. > I understand the view that this should not break (reasonably) deployed > existing networks and this may require some reconsideration. However, I > don't think that this change to require id-kp-serverAuth to be present > would be good either since it would likely break even more use cases. It > might be more reasonable to reject the server based on id-kp-clientAuth > being present without id-kp-serverAuth. We don’t reject if the EKU extension is missing entirely, and my patch doesn’t change that. Are you worried about certificates that explicitly include an EKU extension listing none of id-kp-clientAuth, id-kp-serverAuth, or anyExtendedKeyUsage? > Would it be possible to get the MIT SECURE server certificate that hits > this new constraint on id-kp-clientAuth being present? This would be > useful for further discussion on possible spec changes/clarifications. Can I extract it from wpa_supplicant? (I don’t have any kind of special access to the servers. All that MIT provides is these fingerprints: http://kb.mit.edu/confluence/x/YgAwB .) Anders
On Sat, Feb 15, 2014 at 05:24:38AM -0500, Anders Kaseorg wrote: > I’m not seeing that specification requirement. I looked at EAP-TLS > (RFC 5216): > This is all about requiring certain key usage values to be included; > there’s nothing about requiring other values to be excluded. I know. I was referring to a different specification (sorry, cannot talk about details yet). > We don’t reject if the EKU extension is missing entirely, and my > patch doesn’t change that. Are you worried about certificates that > explicitly include an EKU extension listing none of > id-kp-clientAuth, id-kp-serverAuth, or anyExtendedKeyUsage? To be honest, I did not notice that, but I was thinking of not including id-kp-serverAuth and now that you say it, I guess that could also happen with an EKU (for something completely different) being included. I don't think id-kp-serverAuth is universally used, so I don't really want to mandate it. id-kp-clientAuth alone is actually already rejected by OpenSSL, so no need for that separately in tls_openssl.c. > >Would it be possible to get the MIT SECURE server certificate that hits > >this new constraint on id-kp-clientAuth being present? This would be > >useful for further discussion on possible spec changes/clarifications. > > Can I extract it from wpa_supplicant? (I don’t have any kind of > special access to the servers. All that MIT provides is these > fingerprints: http://kb.mit.edu/confluence/x/YgAwB .) You can extract the server certificate with a connection to probe for such information. For example, in wpa_cli: add_network set_network 0 ssid "your ssid" set_network 0 key_mgmt WPA-EAP set_network 0 eap TTLS set_network 0 identity "probe" set_network 0 ca_cert "probe://" select_network 0 ... CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=FI/O=w1.fi/CN=server.w1.fi' cert=30820295308201.... There's going to be number of CTRL-EVENT-EAP-PEER-CERT events listed here. I'm most interested in the one with depth=0 and cert=<hexdump> value which is the hexdump of the DER encoding X.509 certificate of the authentication server. Anyway, if you can send all those CTRL-EVENT-EAP-PEER-CERT events, that would give even better picture by including all the CA certificates.
>> This is all about requiring certain key usage values to be included; >> there’s nothing about requiring other values to be excluded. > I know. I was referring to a different specification (sorry, cannot > talk about details yet). I'm having trouble imagining a valid reason for anyone to try to respecify X.509 EKU purposes as restrictive via an embargoed document. http://tools.ietf.org/html/rfc5280#section-4.2.1.12 makes it clear that key purposes are permissive, although the presence of an EKU at all is restrictive (if the application understands what EKUs are or if the extension is marked critical). Every web server SSL certificate I can find contains an EKU with id-kp-clientAuth and id-kp-serverAuth, leading me to believe that CAs issue certificates with both purposes as a matter of course, and that this check probably breaks most real-world usage of WPA.
On Sat, 15 Feb 2014, Jouni Malinen wrote: > I know. I was referring to a different specification (sorry, cannot talk > about details yet). It’s not that I don’t believe you, but you realize how this sounds, right? How am I going to supposed to explain to the MIT network team that they need to “fix” their certificate that already conforms with every published specification and works with every client except wpa_supplicant 2.1? (Most Linux users aren’t even going to notice this problem for a while because Fedora is still on 2.0 and Debian/Ubuntu are stuck at 1.0 because of regressions in later versions. I only noticed because I’m trying to help get Debian/Ubuntu unstuck, but I worry that the maintainers aren’t going to be encouraged by the current state.) > To be honest, I did not notice that, but I was thinking of not including > id-kp-serverAuth and now that you say it, I guess that could also happen > with an EKU (for something completely different) being included. I don't > think id-kp-serverAuth is universally used, so I don't really want to > mandate it. id-kp-clientAuth alone is actually already rejected by > OpenSSL, so no need for that separately in tls_openssl.c. Okay, then it sounds like the most reasonable solution is reverting commit 51e3eafb68e15e78e98ca955704be8a6c3a7b304. > CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=FI/O=w1.fi/CN=server.w1.fi' cert=30820295308201.... While trying to extract these certificates, I ran into both a 256-byte wpa_cli limit and a 2048-byte wpa_supplicant limit on the length of that control message. After fixing the latter (will send this patch) and arbitrarily bumping up the former (we should do something about that too), I’ve extracted the following: <3>CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA' hash=d4c4c99819f3a5f2c6261c9444c62a8b263b39bc6acce35cdcabe272d5037fb2 <3>CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA' cert=308203d9308202c1a00302010202030236d0300d06092a864886f70d01010505003042310b300906035504061302555331163014060355040a130d47656f547275737420496e632e311b30190603550403131247656f547275737420476c6f62616c204341301e170d3130303231393232333932365a170d3230303231383232333932365a3040310b300906035504061302555331173015060355040a130e47656f54727573742c20496e632e311830160603550403130f47656f54727573742053534c20434130820122300d06092a864886f70d01010105000382010f003082010a028201010090b380c1e4e546ad70603dbae514dd9e8a5e8b755ae6ca6d41a523e83985267aa755779a48a1927e3a1e1af127aba34c39cccb3d47af81ae166a5c37ef4541fdfb9a973ca0439dc6df1721d18aa256c203498412813ec90a546066b98c54e4f9e6f994f1e05f7511f229b9e486a2b189ada61e832963b2f0541c850b7ae7e12e0dafa4bdcde7b15ad78c055a0e4b73288b755d34d8770be17462e2713062d8bc8a05e531634a54896a3378a74e55241d97ef1ae412c60f3018b4344de1d8233b215b2d3019250e74f7a4214ba0a420c96ccd9856c0f2a85f3e2675a00df836888a2c5a7d6730a90fd199702e78e15126af557a24be8c390d779dde02c30cbd1f0203010001a381d93081d6300e0603551d0f0101ff040403020106301d0603551d0e041604144279541b61cd552b3e63d53c4857f59ffb45ce4a301f0603551d23041830168014c07a98688d89fbab05640c117daa7d65b8cacc4e30120603551d130101ff040830060101ff020100303a0603551d1f04333031302fa02da02b8629687474703a2f2f63726c2e67656f74727573742e636f6d2f63726c732f6774676c6f62616c2e63726c303406082b0601050507010104283026302406082b060105050730018618687474703a2f2f6f6373702e67656f74727573742e636f6d300d06092a864886f70d01010505000382010100d4ef5384e81abda18b04c0a9f55fa11078455db2576a4e24cb654e3197919ad424f8e2276670319cc1625406e7971d3a9ac0a429480aaf24c7a8c49a54c17c4c784c2b682c5d17a654784c46e280c31f387112d2d753e3548550b802cbee633af856894d55bb2ec0c8187786310b0b70f07e3583a42a13645667345d165f73ac7b0624da4f506d2aabd04d5341c28ebb710349298618cf21424c74625115c56fa8efc427e51b33dd5a88d77f12d1a761251fd5e0dc1dcf1a10d8a0cb5f8cfa0ce5bf71ffe55d441da63e8747fa1a4e8383123f88669598799a85eb0247cd25e3f206044e99ca5ca06e7abbdda3901a4533efbf3ed204c4b6e02a8565413e10d4 <3>CTRL-EVENT-EAP-STATUS status='remote certificate verification' parameter='success' <3>CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/serialNumber=cVycYduKJuN-QJPtPROOvgg5Rmr8DMNh/C=US/ST=Massachusetts/L=Cambridge/O=Massachusetts Institute of Technology/OU=Information Services and Technology/CN=wireless-radius-2.mit.edu' hash=b4ec7484d07a6a40ad9c700b1ac7557dcceb8f19331449ca0bed9c7c52bba315 <3>CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/serialNumber=cVycYduKJuN-QJPtPROOvgg5Rmr8DMNh/C=US/ST=Massachusetts/L=Cambridge/O=Massachusetts Institute of Technology/OU=Information Services and Technology/CN=wireless-radius-2.mit.edu' cert=308204d1308203b9a003020102020301639f300d06092a864886f70d01010505003040310b300906035504061302555331173015060355040a130e47656f54727573742c20496e632e311830160603550403130f47656f54727573742053534c204341301e170d3132303530313232323730315a170d3137303630333132323430305a3081e63129302706035504051320635679635964754b4a754e2d514a507450524f4f76676735526d7238444d4e68310b3009060355040613025553311630140603550408130d4d617373616368757365747473311230100603550407130943616d627269646765312e302c060355040a13254d61737361636875736574747320496e73746974757465206f6620546563686e6f6c6f6779312c302a060355040b1323496e666f726d6174696f6e20536572766963657320616e6420546563686e6f6c6f67793122302006035504031319776972656c6573732d7261646975732d322e6d69742e65647530820122300d06092a864886f70d01010105000382010f003082010a0282010100daad919238fd2772dc25ee70dcad77051e8802ee35728f038ad3475d5102e603b966ece40ee0ef38c743176e4a85ab05344057baa08bc533a58bf8a6d257d40eac53e23deb26547a8ee159896fbe6c5b83a1487b45176f5dca2c749f05353eba34395c8d9e1e6713c253470d52054ab31b19f5254c2d6b5e91724dc8dca74933154ade57ad83e83371b3dc80bb8384ceed34205893452bb6fe2520fa0e063b2190ea28e2841d9fcafbebe0335e798449d374143b620090fe2894dde8b505665ade13766033108863f0b174da57071852f6e1751cc6f32f4be6bae1971c3433d86f6cbebacb25ef69ddf6d980142b3240e43783e3860023ab991f9419c676404b0203010001a382012b30820127301f0603551d230418301680144279541b61cd552b3e63d53c4857f59ffb45ce4a300e0603551d0f0101ff0404030204b0301d0603551d250416301406082b0601050507030106082b0601050507030230240603551d11041d301b8219776972656c6573732d7261646975732d322e6d69742e656475303d0603551d1f043630343032a030a02e862c687474703a2f2f677473736c2d63726c2e67656f74727573742e636f6d2f63726c732f677473736c2e63726c301d0603551d0e04160414f908c9f752e140281f2fbc6fd4152bfab4a992fb300c0603551d130101ff04023000304306082b0601050507010104373035303306082b060105050730028627687474703a2f2f677473736c2d6169612e67656f74727573742e636f6d2f677473736c2e637274300d06092a864886f70d0101050500038201010041c877631516d82045033bd0730aa35e5ed7032fbdb0312f3a6a3fcdfd93345f68a44b739ec498065f44352aff187918d1ab6be6d85bebda3a5c4f0c8e1287daab02ea62e7c480427b74db973a9002d4822773f6bf433d9c5e0dd53f76303d7aab0ddb2273b247cb930d1dadc805ba51827f8e625d38bfd76c4fbc1764adc02a5925dfa519b33993093ffcdfbadc247ba3af38a44ab22e03856d339f7caa691d1f3cd334589dec4d0c5178e23fe5408f29299fdb7f776240455977d76b54f1abb9ff926b1b3dcf9907e13e512b3f94376dcfd025793be865f1a14b00a12961570c77a270287b43ec329f40ba30a067e46608447564196210b883dfc7543b8c05 <3>CTRL-EVENT-EAP-TLS-CERT-ERROR reason=8 depth=0 subject='/serialNumber=cVycYduKJuN-QJPtPROOvgg5Rmr8DMNh/C=US/ST=Massachusetts/L=Cambridge/O=Massachusetts Institute of Technology/OU=Information Services and Technology/CN=wireless-radius-2.mit.edu' err='Server certificate chain probe' Certificate: Data: Version: 3 (0x2) Serial Number: 145104 (0x236d0) Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=GeoTrust Inc., CN=GeoTrust Global CA Validity Not Before: Feb 19 22:39:26 2010 GMT Not After : Feb 18 22:39:26 2020 GMT Subject: C=US, O=GeoTrust, Inc., CN=GeoTrust SSL CA Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:90:b3:80:c1:e4:e5:46:ad:70:60:3d:ba:e5:14: dd:9e:8a:5e:8b:75:5a:e6:ca:6d:41:a5:23:e8:39: 85:26:7a:a7:55:77:9a:48:a1:92:7e:3a:1e:1a:f1: 27:ab:a3:4c:39:cc:cb:3d:47:af:81:ae:16:6a:5c: 37:ef:45:41:fd:fb:9a:97:3c:a0:43:9d:c6:df:17: 21:d1:8a:a2:56:c2:03:49:84:12:81:3e:c9:0a:54: 60:66:b9:8c:54:e4:f9:e6:f9:94:f1:e0:5f:75:11: f2:29:b9:e4:86:a2:b1:89:ad:a6:1e:83:29:63:b2: f0:54:1c:85:0b:7a:e7:e1:2e:0d:af:a4:bd:cd:e7: b1:5a:d7:8c:05:5a:0e:4b:73:28:8b:75:5d:34:d8: 77:0b:e1:74:62:e2:71:30:62:d8:bc:8a:05:e5:31: 63:4a:54:89:6a:33:78:a7:4e:55:24:1d:97:ef:1a: e4:12:c6:0f:30:18:b4:34:4d:e1:d8:23:3b:21:5b: 2d:30:19:25:0e:74:f7:a4:21:4b:a0:a4:20:c9:6c: cd:98:56:c0:f2:a8:5f:3e:26:75:a0:0d:f8:36:88: 8a:2c:5a:7d:67:30:a9:0f:d1:99:70:2e:78:e1:51: 26:af:55:7a:24:be:8c:39:0d:77:9d:de:02:c3:0c: bd:1f Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Subject Key Identifier: 42:79:54:1B:61:CD:55:2B:3E:63:D5:3C:48:57:F5:9F:FB:45:CE:4A X509v3 Authority Key Identifier: keyid:C0:7A:98:68:8D:89:FB:AB:05:64:0C:11:7D:AA:7D:65:B8:CA:CC:4E X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 CRL Distribution Points: Full Name: URI:http://crl.geotrust.com/crls/gtglobal.crl Authority Information Access: OCSP - URI:http://ocsp.geotrust.com Signature Algorithm: sha1WithRSAEncryption d4:ef:53:84:e8:1a:bd:a1:8b:04:c0:a9:f5:5f:a1:10:78:45: 5d:b2:57:6a:4e:24:cb:65:4e:31:97:91:9a:d4:24:f8:e2:27: 66:70:31:9c:c1:62:54:06:e7:97:1d:3a:9a:c0:a4:29:48:0a: af:24:c7:a8:c4:9a:54:c1:7c:4c:78:4c:2b:68:2c:5d:17:a6: 54:78:4c:46:e2:80:c3:1f:38:71:12:d2:d7:53:e3:54:85:50: b8:02:cb:ee:63:3a:f8:56:89:4d:55:bb:2e:c0:c8:18:77:86: 31:0b:0b:70:f0:7e:35:83:a4:2a:13:64:56:67:34:5d:16:5f: 73:ac:7b:06:24:da:4f:50:6d:2a:ab:d0:4d:53:41:c2:8e:bb: 71:03:49:29:86:18:cf:21:42:4c:74:62:51:15:c5:6f:a8:ef: c4:27:e5:1b:33:dd:5a:88:d7:7f:12:d1:a7:61:25:1f:d5:e0: dc:1d:cf:1a:10:d8:a0:cb:5f:8c:fa:0c:e5:bf:71:ff:e5:5d: 44:1d:a6:3e:87:47:fa:1a:4e:83:83:12:3f:88:66:95:98:79: 9a:85:eb:02:47:cd:25:e3:f2:06:04:4e:99:ca:5c:a0:6e:7a: bb:dd:a3:90:1a:45:33:ef:bf:3e:d2:04:c4:b6:e0:2a:85:65: 41:3e:10:d4 -----BEGIN CERTIFICATE----- MIID2TCCAsGgAwIBAgIDAjbQMA0GCSqGSIb3DQEBBQUAMEIxCzAJBgNVBAYTAlVT MRYwFAYDVQQKEw1HZW9UcnVzdCBJbmMuMRswGQYDVQQDExJHZW9UcnVzdCBHbG9i YWwgQ0EwHhcNMTAwMjE5MjIzOTI2WhcNMjAwMjE4MjIzOTI2WjBAMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOR2VvVHJ1c3QsIEluYy4xGDAWBgNVBAMTD0dlb1RydXN0 IFNTTCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJCzgMHk5Uat cGA9uuUU3Z6KXot1WubKbUGlI+g5hSZ6p1V3mkihkn46HhrxJ6ujTDnMyz1Hr4Gu FmpcN+9FQf37mpc8oEOdxt8XIdGKolbCA0mEEoE+yQpUYGa5jFTk+eb5lPHgX3UR 8im55IaisYmtph6DKWOy8FQchQt65+EuDa+kvc3nsVrXjAVaDktzKIt1XTTYdwvh dGLicTBi2LyKBeUxY0pUiWozeKdOVSQdl+8a5BLGDzAYtDRN4dgjOyFbLTAZJQ50 96QhS6CkIMlszZhWwPKoXz4mdaAN+DaIiixafWcwqQ/RmXAueOFRJq9VeiS+jDkN d53eAsMMvR8CAwEAAaOB2TCB1jAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFEJ5 VBthzVUrPmPVPEhX9Z/7Rc5KMB8GA1UdIwQYMBaAFMB6mGiNifurBWQMEX2qfWW4 ysxOMBIGA1UdEwEB/wQIMAYBAf8CAQAwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDov L2NybC5nZW90cnVzdC5jb20vY3Jscy9ndGdsb2JhbC5jcmwwNAYIKwYBBQUHAQEE KDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5nZW90cnVzdC5jb20wDQYJKoZI hvcNAQEFBQADggEBANTvU4ToGr2hiwTAqfVfoRB4RV2yV2pOJMtlTjGXkZrUJPji J2ZwMZzBYlQG55cdOprApClICq8kx6jEmlTBfEx4TCtoLF0XplR4TEbigMMfOHES 0tdT41SFULgCy+5jOvhWiU1Vuy7AyBh3hjELC3DwfjWDpCoTZFZnNF0WX3OsewYk 2k9QbSqr0E1TQcKOu3EDSSmGGM8hQkx0YlEVxW+o78Qn5Rsz3VqI138S0adhJR/V 4NwdzxoQ2KDLX4z6DOW/cf/lXUQdpj6HR/oaToODEj+IZpWYeZqF6wJHzSXj8gYE TpnKXKBuervdo5AaRTPvvz7SBMS24CqFZUE+ENQ= -----END CERTIFICATE----- Certificate: Data: Version: 3 (0x2) Serial Number: 91039 (0x1639f) Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, O=GeoTrust, Inc., CN=GeoTrust SSL CA Validity Not Before: May 1 22:27:01 2012 GMT Not After : Jun 3 12:24:00 2017 GMT Subject: serialNumber=cVycYduKJuN-QJPtPROOvgg5Rmr8DMNh, C=US, ST=Massachusetts, L=Cambridge, O=Massachusetts Institute of Technology, OU=Information Services and Technology, CN=wireless-radius-2.mit.edu Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:da:ad:91:92:38:fd:27:72:dc:25:ee:70:dc:ad: 77:05:1e:88:02:ee:35:72:8f:03:8a:d3:47:5d:51: 02:e6:03:b9:66:ec:e4:0e:e0:ef:38:c7:43:17:6e: 4a:85:ab:05:34:40:57:ba:a0:8b:c5:33:a5:8b:f8: a6:d2:57:d4:0e:ac:53:e2:3d:eb:26:54:7a:8e:e1: 59:89:6f:be:6c:5b:83:a1:48:7b:45:17:6f:5d:ca: 2c:74:9f:05:35:3e:ba:34:39:5c:8d:9e:1e:67:13: c2:53:47:0d:52:05:4a:b3:1b:19:f5:25:4c:2d:6b: 5e:91:72:4d:c8:dc:a7:49:33:15:4a:de:57:ad:83: e8:33:71:b3:dc:80:bb:83:84:ce:ed:34:20:58:93: 45:2b:b6:fe:25:20:fa:0e:06:3b:21:90:ea:28:e2: 84:1d:9f:ca:fb:eb:e0:33:5e:79:84:49:d3:74:14: 3b:62:00:90:fe:28:94:dd:e8:b5:05:66:5a:de:13: 76:60:33:10:88:63:f0:b1:74:da:57:07:18:52:f6: e1:75:1c:c6:f3:2f:4b:e6:ba:e1:97:1c:34:33:d8: 6f:6c:be:ba:cb:25:ef:69:dd:f6:d9:80:14:2b:32: 40:e4:37:83:e3:86:00:23:ab:99:1f:94:19:c6:76: 40:4b Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Authority Key Identifier: keyid:42:79:54:1B:61:CD:55:2B:3E:63:D5:3C:48:57:F5:9F:FB:45:CE:4A X509v3 Key Usage: critical Digital Signature, Key Encipherment, Data Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Subject Alternative Name: DNS:wireless-radius-2.mit.edu X509v3 CRL Distribution Points: Full Name: URI:http://gtssl-crl.geotrust.com/crls/gtssl.crl X509v3 Subject Key Identifier: F9:08:C9:F7:52:E1:40:28:1F:2F:BC:6F:D4:15:2B:FA:B4:A9:92:FB X509v3 Basic Constraints: critical CA:FALSE Authority Information Access: CA Issuers - URI:http://gtssl-aia.geotrust.com/gtssl.crt Signature Algorithm: sha1WithRSAEncryption 41:c8:77:63:15:16:d8:20:45:03:3b:d0:73:0a:a3:5e:5e:d7: 03:2f:bd:b0:31:2f:3a:6a:3f:cd:fd:93:34:5f:68:a4:4b:73: 9e:c4:98:06:5f:44:35:2a:ff:18:79:18:d1:ab:6b:e6:d8:5b: eb:da:3a:5c:4f:0c:8e:12:87:da:ab:02:ea:62:e7:c4:80:42: 7b:74:db:97:3a:90:02:d4:82:27:73:f6:bf:43:3d:9c:5e:0d: d5:3f:76:30:3d:7a:ab:0d:db:22:73:b2:47:cb:93:0d:1d:ad: c8:05:ba:51:82:7f:8e:62:5d:38:bf:d7:6c:4f:bc:17:64:ad: c0:2a:59:25:df:a5:19:b3:39:93:09:3f:fc:df:ba:dc:24:7b: a3:af:38:a4:4a:b2:2e:03:85:6d:33:9f:7c:aa:69:1d:1f:3c: d3:34:58:9d:ec:4d:0c:51:78:e2:3f:e5:40:8f:29:29:9f:db: 7f:77:62:40:45:59:77:d7:6b:54:f1:ab:b9:ff:92:6b:1b:3d: cf:99:07:e1:3e:51:2b:3f:94:37:6d:cf:d0:25:79:3b:e8:65: f1:a1:4b:00:a1:29:61:57:0c:77:a2:70:28:7b:43:ec:32:9f: 40:ba:30:a0:67:e4:66:08:44:75:64:19:62:10:b8:83:df:c7: 54:3b:8c:05 -----BEGIN CERTIFICATE----- MIIE0TCCA7mgAwIBAgIDAWOfMA0GCSqGSIb3DQEBBQUAMEAxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5HZW9UcnVzdCwgSW5jLjEYMBYGA1UEAxMPR2VvVHJ1c3QgU1NM IENBMB4XDTEyMDUwMTIyMjcwMVoXDTE3MDYwMzEyMjQwMFowgeYxKTAnBgNVBAUT IGNWeWNZZHVLSnVOLVFKUHRQUk9PdmdnNVJtcjhETU5oMQswCQYDVQQGEwJVUzEW MBQGA1UECBMNTWFzc2FjaHVzZXR0czESMBAGA1UEBxMJQ2FtYnJpZGdlMS4wLAYD VQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5MSwwKgYD VQQLEyNJbmZvcm1hdGlvbiBTZXJ2aWNlcyBhbmQgVGVjaG5vbG9neTEiMCAGA1UE AxMZd2lyZWxlc3MtcmFkaXVzLTIubWl0LmVkdTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBANqtkZI4/Sdy3CXucNytdwUeiALuNXKPA4rTR11RAuYDuWbs 5A7g7zjHQxduSoWrBTRAV7qgi8UzpYv4ptJX1A6sU+I96yZUeo7hWYlvvmxbg6FI e0UXb13KLHSfBTU+ujQ5XI2eHmcTwlNHDVIFSrMbGfUlTC1rXpFyTcjcp0kzFUre V62D6DNxs9yAu4OEzu00IFiTRSu2/iUg+g4GOyGQ6ijihB2fyvvr4DNeeYRJ03QU O2IAkP4olN3otQVmWt4TdmAzEIhj8LF02lcHGFL24XUcxvMvS+a64ZccNDPYb2y+ ussl72nd9tmAFCsyQOQ3g+OGACOrmR+UGcZ2QEsCAwEAAaOCASswggEnMB8GA1Ud IwQYMBaAFEJ5VBthzVUrPmPVPEhX9Z/7Rc5KMA4GA1UdDwEB/wQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwJAYDVR0RBB0wG4IZd2lyZWxlc3Mt cmFkaXVzLTIubWl0LmVkdTA9BgNVHR8ENjA0MDKgMKAuhixodHRwOi8vZ3Rzc2wt Y3JsLmdlb3RydXN0LmNvbS9jcmxzL2d0c3NsLmNybDAdBgNVHQ4EFgQU+QjJ91Lh QCgfL7xv1BUr+rSpkvswDAYDVR0TAQH/BAIwADBDBggrBgEFBQcBAQQ3MDUwMwYI KwYBBQUHMAKGJ2h0dHA6Ly9ndHNzbC1haWEuZ2VvdHJ1c3QuY29tL2d0c3NsLmNy dDANBgkqhkiG9w0BAQUFAAOCAQEAQch3YxUW2CBFAzvQcwqjXl7XAy+9sDEvOmo/ zf2TNF9opEtznsSYBl9ENSr/GHkY0atr5thb69o6XE8MjhKH2qsC6mLnxIBCe3Tb lzqQAtSCJ3P2v0M9nF4N1T92MD16qw3bInOyR8uTDR2tyAW6UYJ/jmJdOL/XbE+8 F2StwCpZJd+lGbM5kwk//N+63CR7o684pEqyLgOFbTOffKppHR880zRYnexNDFF4 4j/lQI8pKZ/bf3diQEVZd9drVPGruf+Saxs9z5kH4T5RKz+UN23P0CV5O+hl8aFL AKEpYVcMd6JwKHtD7DKfQLowoGfkZghEdWQZYhC4g9/HVDuMBQ== -----END CERTIFICATE----- Anders
On Sat, Feb 15, 2014 at 07:05:05PM -0500, Anders Kaseorg wrote: > How am I going to supposed to explain to the MIT network team that they > need to “fix” their certificate that already conforms with every published > specification and works with every client except wpa_supplicant 2.1? Just to be clear: I have not and do not in any way suggest that the AAA server certificate here should be changed. > Okay, then it sounds like the most reasonable solution is reverting commit > 51e3eafb68e15e78e98ca955704be8a6c3a7b304. Probably yes. The unfortunate part here is that there seems to be a conflicting requirement in this area. Hopefully, that requirement can be changed, but if not, this is going to be much wider issue and something else is going to be needed to work around this. > While trying to extract these certificates, I ran into both a 256-byte > wpa_cli limit and a 2048-byte wpa_supplicant limit on the length of that > control message. After fixing the latter (will send this patch) and > arbitrarily bumping up the former (we should do something about that too), > I’ve extracted the following: Thanks! This is exactly the information I need for trying to get the requirement side resolved.
On Sat, Feb 15, 2014 at 07:05:05PM -0500, Anders Kaseorg wrote: > Okay, then it sounds like the most reasonable solution is reverting commit > 51e3eafb68e15e78e98ca955704be8a6c3a7b304. I did that now. I don't yet know what will happen with the other conflicting requirements in this area, but I'll try to get them changed and at least keep this use case in mind as far as wpa_supplicant implementation is concerned. There is now a regression test case that verifies interop with this type of AAA server certificate.
diff --git a/src/crypto/tls.h b/src/crypto/tls.h index 287fd33..3f07600 100644 --- a/src/crypto/tls.h +++ b/src/crypto/tls.h @@ -42,7 +42,7 @@ enum tls_fail_reason { TLS_FAIL_BAD_CERTIFICATE = 7, TLS_FAIL_SERVER_CHAIN_PROBE = 8, TLS_FAIL_DOMAIN_SUFFIX_MISMATCH = 9, - TLS_FAIL_SERVER_USED_CLIENT_CERT = 10 + TLS_FAIL_NON_SERVER_KEY_USAGE = 10, }; union tls_event_data { diff --git a/src/crypto/tls_openssl.c b/src/crypto/tls_openssl.c index d025ae0..485a21e 100644 --- a/src/crypto/tls_openssl.c +++ b/src/crypto/tls_openssl.c @@ -1479,11 +1479,13 @@ static int tls_verify_cb(int preverify_ok, X509_STORE_CTX *x509_ctx) if (!conn->server && err_cert && preverify_ok && depth == 0 && (err_cert->ex_flags & EXFLAG_XKUSAGE) && - (err_cert->ex_xkusage & XKU_SSL_CLIENT)) { - wpa_printf(MSG_WARNING, "TLS: Server used client certificate"); + !(err_cert->ex_xkusage & XKU_SSL_SERVER)) { + wpa_printf(MSG_WARNING, "TLS: Server certificate marked for " + "non-server key usage"); openssl_tls_fail_event(conn, err_cert, err, depth, buf, - "Server used client certificate", - TLS_FAIL_SERVER_USED_CLIENT_CERT); + "Server certificate marked for " + "non-server key usage", + TLS_FAIL_NON_SERVER_KEY_USAGE); preverify_ok = 0; }
Commit 51e3eafb68e15e78e98ca955704be8a6c3a7b304 was too strict in forbidding certificates marked for client use. For example, this broke the MIT SECURE wireless network. The extended key usage is a _list_ of allowed uses, and rather than checking that client use is not in the list, we should check that server use is in the list. Signed-off-by: Anders Kaseorg <andersk@mit.edu> --- src/crypto/tls.h | 2 +- src/crypto/tls_openssl.c | 10 ++++++---- 2 files changed, 7 insertions(+), 5 deletions(-)