Concerns for distribution of CA cert

[maltfield]

Hi,

I think the distribution of the recent CA cert change could have been greatly improved by cryptographically signing the replacement cert in a way that can be verified out-of-band.

Correct me if I'm wrong, but this single file is absolutely crucial to obtaining confidentiality when using the cryptstorm vpn service.

* https://cryptostorm.is/ca.txt
* https://github.com/cryptostorm/cryptost ... ter/ca.crt

If someone was able to modify the contents of this ca.txt file while I'm downloading its new version, they would be able to effectively man-in-the-middle all of my traffic to cryptostorm. After doing so, they could see all the sites I visited and all of the contents of my traffic that isn't end-to-end encrypted (lest the MITM those connections too!).

The official notice that advertised this change of CA is here:

* https://cryptostorm.is/newCA

The contents of this message was sadly very terse:

The CA certificate our OpenVPN setup uses is set to expire on Dec 22, so we've had to generate new ones.
That means by Dec 22, all members need to be using the latest one.

The configuration files at GitHub have already been updated with the new CA.

If you want to modify your existing configs manually, you can get the latest CA from https://cryptostorm.is/ca.txt

If you are using v2.22 or v3.0 of the widget, you'll need to upgrade to the new v3.1 widget at https://cryptostorm.is/cryptostorm_setup.exe (hashes available here)
Due to a bug in the self-updating code in v3.0, the widget will NOT automatically upgrade to v3.1. You'll have to manually download/install it from the above link.
If you're still using v2.22, the updating code there will still work since that version just did a simple `start https://cryptostorm.nu/setup.exe`, and setup.exe there has been updated to v3.1.
v3.1 of the widget is using the latest OpenVPN 2.4.x, which means XP is no longer supported.
If you require XP for some reason, you can use an older version of OpenVPN GUI to connect, although even that will most likely stop being supported in the near future.

Note: You can still connect using the old CA certificate, but after Dec 22 OpenVPN will show a fatal error that the CA certificate you're using has expired.

Nothing in the above message mentioned any way to verify the integrity of the new file out-of-band! Therefore, if someone was MITM'ing the TLS connection between the client & https://cryptostorm.is (which is trivial for many powerful multinational corporations & state actors that own CAs whitelisted by our browsers), they'd be able to arbitrarily hand me any contents of the 'ca.txt' file, and then intercept all my future traffic with cryptostorm over my vpn connection.

My proposal is:

add a <pre></pre> block on the page 'https://cryptostorm.is/newCA' with an clearsigned pgp message. The signed message should

1. state the reason for the change
2. include the new cert and
3. describe how to validate the authenticity & integrity of the new key

Obviously the cryptstorm team recognizes the risks of authentication within the X.509 PKI trust model. This is why the certificate is pinned when connecting to crytostorm--it prevents the risk of a man-in-the-middle injecting their own CA. However, releasing an updated version of that pinned CA for clients to download over the same untrusted X.509 trust model (especially when https://cryptostorm.is doesn't even use HSTS or HPKP!) is a huge security risk.

Code: Select all

user@personal:~$ curl -i https://cryptostorm.is/ca.txt 
HTTP/1.1 200 OK
Date: Sun, 24 Dec 2017 16:03:42 GMT
Server: Apache
x-frame-options: SAMEORIGIN
Last-Modified: Mon, 18 Dec 2017 07:24:22 GMT
Accept-Ranges: bytes
Content-Length: 1866
Content-Type: text/plain

-----BEGIN CERTIFICATE----- 
MIIFIDCCBAigAwIBAgIJAKekpGXxXvhbMA0GCSqGSIb3DQEBCwUAMIG6MQswCQYD 
VQQGEwJDQTELMAkGA1UECBMCUUMxETAPBgNVBAcTCE1vbnRyZWFsMTYwNAYDVQQK 
FC1LYXRhbmEgSG9sZGluZ3MgTGltaXRlIC8gIGNyeXB0b3N0b3JtX2RhcmtuZXQx 
ETAPBgNVBAsTCFRlY2ggT3BzMRcwFQYDVQQDFA5jcnlwdG9zdG9ybV9pczEnMCUG 
CSqGSIb3DQEJARYYY2VydGFkbWluQGNyeXB0b3N0b3JtLmlzMCAXDTE3MTIxNjA3 
NTk0MloYDzIwNjcxMjE2MDc1OTQyWjCBujELMAkGA1UEBhMCQ0ExCzAJBgNVBAgT 
AlFDMREwDwYDVQQHEwhNb250cmVhbDE2MDQGA1UEChQtS2F0YW5hIEhvbGRpbmdz 
IExpbWl0ZSAvICBjcnlwdG9zdG9ybV9kYXJrbmV0MREwDwYDVQQLEwhUZWNoIE9w 
czEXMBUGA1UEAxQOY3J5cHRvc3Rvcm1faXMxJzAlBgkqhkiG9w0BCQEWGGNlcnRh 
ZG1pbkBjcnlwdG9zdG9ybS5pczCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC 
ggEBAMlo5Jghf+yb7j86QKDIA9gH9U+MOj1gFz7POcobF3UXx8CR6py4+kY0LEwE 
s66YuwF3Et1Haymkrxy72RjHqD58FRC1KGg6PzhDr6foXgOpuOweUvBTLS6WR5Ba 
TW+8oqSkFWIZUWxnk4N1npxonZRjYLjU4AJNB1uUKpp5uwtC+n9UYpNZ2H1SwZDc 
tpJNzG3Q+ySqkaJYRR44YbeYoTQpbK/G3o7H2Kz1BsNck5h2SVBo9f3JS4gjTcaP 
fGb6+Lqra/MPlXKY55MzKTLsZ5q1t3ZTjn0vDO7+D7xXoRCXyq9atcRJf9ldm80b 
xABw5dTiS00E6hm3CzpPOSelAXcCAwEAAaOCASMwggEfMAwGA1UdEwQFMAMBAf8w 
HQYDVR0OBBYEFDhY4fdfMy+L0fMdat75Kep6cFElMIHvBgNVHSMEgecwgeSAFDhY 
4fdfMy+L0fMdat75Kep6cFEloYHApIG9MIG6MQswCQYDVQQGEwJDQTELMAkGA1UE 
CBMCUUMxETAPBgNVBAcTCE1vbnRyZWFsMTYwNAYDVQQKFC1LYXRhbmEgSG9sZGlu 
Z3MgTGltaXRlIC8gIGNyeXB0b3N0b3JtX2RhcmtuZXQxETAPBgNVBAsTCFRlY2gg 
T3BzMRcwFQYDVQQDFA5jcnlwdG9zdG9ybV9pczEnMCUGCSqGSIb3DQEJARYYY2Vy 
dGFkbWluQGNyeXB0b3N0b3JtLmlzggkAp6SkZfFe+FswDQYJKoZIhvcNAQELBQAD 
ggEBABrPLmFpugICgUKyJ+6q5h8ZKfoV3S0RtTfrwtobNSFf7H4ZQvCXF2bOuhyc 
g00ffreEGZN2uwtiLh38ncB/BFhHfgkITfTe88m08pJ45PkrpeBfrFbZ+ckXVhV/ 
aCnUKkIZgmCNKnn1RIbUt4mzTzggwtN3GamoTzSWqSwCEO9Ig1AJKi5Ms/5Awtdz 
nr95qaqI0ih0NGnfC/yIGYvt1Yay0hCil3jIUT9Ogdw6DW6RqUdJaPrwm58fTwIR 
U33KzBqGs8r3UEIMWXuIGc6eXOm2Br08iFgOsUPGqp1ulvD52pFH1o1vT21v3aXl 
D9Ier/83JLMnBGctT1Kzs9OP/U0=
-----END CERTIFICATE-----

Does there exist any way to currently validate the authenticity & integrity of the newly distributed CA cert out-of-band? If not, what are your thoughts on implementing the above-suggested solution?


Cheers,

[df]

The new CA certificate was signed using the same private key that the old certificate was signed with, in a way that allowed us to accept clients using either the old or new CA certificate. That is, until Dec 22 came around, causing a fatal error for anyone still using the old certificate.

That means the modulus and exponent stays the same for the old or new CA certificate:

Code: Select all

[root@b ~]# openssl x509 -noout -modulus -in oldca.crt;openssl x509 -noout -text -in oldca.crt|grep Exp
Modulus=C968E498217FEC9BEE3F3A40A0C803D807F54F8C3A3D60173ECF39CA1B177517C7C091EA9CB8FA46342C4C04B3AE98BB017712DD476B29A4AF1CBBD918C7A83E7C1510B528683A3F3843AFA7E85E03A9B8EC1E52F0532D2E9647905A4D6FBCA2A4A4156219516C679383759E9C689D946360B8D4E0024D075B942A9A79BB0B42FA7F54629359D87D52C190DCB6924DCC6DD0FB24AA91A258451E3861B798A134296CAFC6DE8EC7D8ACF506C35C939876495068F5FDC94B88234DC68F7C66FAF8BAAB6BF30F957298E793332932EC679AB5B776538E7D2F0CEEFE0FBC57A11097CAAF5AB5C4497FD95D9BCD1BC40070E5D4E24B4D04EA19B70B3A4F3927A50177
                Exponent: 65537 (0x10001)

Code: Select all

[root@b ~]# openssl x509 -noout -modulus -in newca.crt;openssl x509 -noout -text -in newca.crt|grep Exp
Modulus=C968E498217FEC9BEE3F3A40A0C803D807F54F8C3A3D60173ECF39CA1B177517C7C091EA9CB8FA46342C4C04B3AE98BB017712DD476B29A4AF1CBBD918C7A83E7C1510B528683A3F3843AFA7E85E03A9B8EC1E52F0532D2E9647905A4D6FBCA2A4A4156219516C679383759E9C689D946360B8D4E0024D075B942A9A79BB0B42FA7F54629359D87D52C190DCB6924DCC6DD0FB24AA91A258451E3861B798A134296CAFC6DE8EC7D8ACF506C35C939876495068F5FDC94B88234DC68F7C66FAF8BAAB6BF30F957298E793332932EC679AB5B776538E7D2F0CEEFE0FBC57A11097CAAF5AB5C4497FD95D9BCD1BC40070E5D4E24B4D04EA19B70B3A4F3927A50177
                Exponent: 65537 (0x10001)

That should be enough verification for anyone concerned with MiTM. Without access to our CA private key, an attacker wouldn't be able to generate their own CA certificate that has the same modulus and exponent as either of our certificates.

See https://tools.ietf.org/html/rfc3447#appendix-A and/or https://major.io/2007/09/14/check-the-m ... h-openssl/ for more info