mullvad.net

Baneki · Postby **Baneki** » Wed Nov 26, 2014 3:00 pm

{direct link: mullvad.cryptostorm.org}

Cofiguration files and keying materials, as published.

mullvadconfig.zip: (78.39 KiB) Downloaded 314 times

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1212117 (0x127ed5)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=NA, ST=None, L=None, O=Mullvad, CN=master.mullvad.net/emailAddress=info@mullvad.net....
        Validity
            Not Before: Jan  1 00:00:00 2009 GMT
            Not After : Nov 23 05:15:31 2024 GMT
        Subject: CN=Mullvad179348453541
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b7:68:4a:09:46:ae:4a:47:a3:01:47:cc:26:59:
                    75:cc:1c:a8:1f:8d:39:e6:4f:0e:7d:c5:9b:9d:d0:
                    ee:0f:cc:73:09:98:ad:26:de:50:e2:99:c3:a4:a2:
                    39:94:2b:a9:00:26:e1:1a:e4:a3:c2:6b:57:c0:78:
                    68:e8:59:35:fd:82:04:b2:48:a6:74:a2:9b:12:24:
                    b9:0d:09:a3:5e:58:84:a4:e9:2e:23:86:ba:80:1a:
                    c3:e0:38:43:35:be:65:e8:0b:cd:2f:ff:a3:be:04:
                    28:ec:46:0f:d0:cc:be:f4:1e:fe:e9:24:9e:a7:ec:
                    f3:38:67:13:a7:5a:31:7d:d6:46:a1:c2:9c:40:d1:
                    f4:0b:49:e9:bb:51:94:88:21:0a:e0:9e:5b:c4:c3:
                    48:a1:81:1b:a3:d2:61:ec:0c:3f:04:6b:58:55:a1:
                    21:de:8c:0b:e2:57:2b:7b:62:07:af:9f:0f:c2:61:
                    b8:af:79:2f:7d:86:c5:28:ea:73:46:a4:9b:a1:f5:
                    6f:02:07:38:5a:4f:4f:a6:e2:d9:e8:05:6e:7e:55:
                    12:b6:90:bf:6e:e8:23:f0:6d:e8:94:61:63:42:61:
                    9b:7f:7d:42:db:d4:91:11:3a:d4:9c:9e:e2:a3:fa:
                    73:25:07:3d:f0:18:e3:de:5a:74:d4:7c:16:51:df:
                    06:ed
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                Easy-RSA Generated Certificate
            X509v3 Subject Key Identifier: 
                82:BB:D3:02:BF:98:31:9C:20:AD:4F:20:21:67:FD:8A:93:E1:AD:CC
            X509v3 Authority Key Identifier: 
                keyid:75:8A:14:92:0D:F3:6E:B7:36:4F:8B:4F:15:6C:3F:18:15:90:64:DE
                DirName:/C=NA/ST=None/L=None/O=Mullvad/CN=Mullvad CA/emailAddress=info@mullvad.net
                serial:03

            X509v3 Extended Key Usage: 
                TLS Web Client Authentication
            X509v3 Key Usage: 
                Digital Signature
    Signature Algorithm: sha1WithRSAEncryption
         4d:ca:5c:cd:e0:9d:4d:cb:bf:d1:09:93:6f:70:60:b1:8f:c1:
         0c:a1:f8:b2:f2:63:9c:af:13:5c:e1:b0:0e:fd:82:48:f2:b3:
         1d:ba:6a:2b:ef:71:fa:6f:2a:d0:76:22:fd:d7:1a:53:82:37:
         ef:31:cf:8c:7d:55:4b:43:43:61:96:70:3e:3c:07:4e:ea:55:
         e7:53:0f:36:fd:36:7d:41:4b:32:88:74:36:39:f1:a3:75:06:
         81:c2:5e:f3:12:a9:5b:ea:12:3e:73:4f:17:7c:ca:5a:eb:07:
         33:1c:81:30:8f:f3:53:6b:29:e6:77:2f:3f:25:61:ad:66:a0:
         0a:52:b6:f6:6c:53:3d:d2:91:5e:32:9c:5c:0d:f9:3e:46:24:
         b6:8e:f2:b4:85:1d:04:ce:60:51:9e:b2:ae:5c:fd:17:d9:bd:
         d5:34:b3:5a:10:86:e0:9f:af:ee:d8:9d:ba:88:7e:fe:4f:c8:
         64:ed:4d:bb:2a:4a:7a:be:f6:9c:9b:cd:93:28:8d:cf:6c:97:
         ff:f6:81:d8:ef:43:c7:8d:9b:73:16:17:8d:e8:2e:47:36:df:
         1c:ba:be:01:df:6b:f7:fd:79:b8:ef:aa:be:fb:93:11:a3:6b:
         3c:fb:67:3d:cd:af:f4:b6:fa:e9:03:6b:05:65:cc:e0:ed:ae:
         c2:84:a8:3c
-----BEGIN CERTIFICATE-----
MIIENzCCAx+gAwIBAgIDEn7VMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAk5B
MQ0wCwYDVQQIEwROb25lMQ0wCwYDVQQHEwROb25lMRAwDgYDVQQKEwdNdWxsdmFk
MRswGQYDVQQDExJtYXN0ZXIubXVsbHZhZC5uZXQxHzAdBgkqhkiG9w0BCQEWEGlu
Zm9AbXVsbHZhZC5uZXQwHhcNMDkwMTAxMDAwMDAwWhcNMjQxMTIzMDUxNTMxWjAe
MRwwGgYDVQQDExNNdWxsdmFkMTc5MzQ4NDUzNTQxMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAt2hKCUauSkejAUfMJll1zByoH4055k8OfcWbndDuD8xz
CZitJt5Q4pnDpKI5lCupACbhGuSjwmtXwHho6Fk1/YIEskimdKKbEiS5DQmjXliE
pOkuI4a6gBrD4DhDNb5l6AvNL/+jvgQo7EYP0My+9B7+6SSep+zzOGcTp1oxfdZG
ocKcQNH0C0npu1GUiCEK4J5bxMNIoYEbo9Jh7Aw/BGtYVaEh3owL4lcre2IHr58P
wmG4r3kvfYbFKOpzRqSbofVvAgc4Wk9PpuLZ6AVuflUStpC/bugj8G3olGFjQmGb
f31C29SRETrUnJ7io/pzJQc98Bjj3lp01HwWUd8G7QIDAQABo4IBHzCCARswCQYD
VR0TBAIwADAtBglghkgBhvhCAQ0EIBYeRWFzeS1SU0EgR2VuZXJhdGVkIENlcnRp
ZmljYXRlMB0GA1UdDgQWBBSCu9MCv5gxnCCtTyAhZ/2Kk+GtzDCBnQYDVR0jBIGV
MIGSgBR1ihSSDfNutzZPi08VbD8YFZBk3qF3pHUwczELMAkGA1UEBhMCTkExDTAL
BgNVBAgTBE5vbmUxDTALBgNVBAcTBE5vbmUxEDAOBgNVBAoTB011bGx2YWQxEzAR
BgNVBAMTCk11bGx2YWQgQ0ExHzAdBgkqhkiG9w0BCQEWEGluZm9AbXVsbHZhZC5u
ZXSCAQMwEwYDVR0lBAwwCgYIKwYBBQUHAwIwCwYDVR0PBAQDAgeAMA0GCSqGSIb3
DQEBBQUAA4IBAQBNylzN4J1Ny7/RCZNvcGCxj8EMofiy8mOcrxNc4bAO/YJI8rMd
umor73H6byrQdiL91xpTgjfvMc+MfVVLQ0NhlnA+PAdO6lXnUw82/TZ9QUsyiHQ2
OfGjdQaBwl7zEqlb6hI+c08XfMpa6wczHIEwj/NTaynmdy8/JWGtZqAKUrb2bFM9
0pFeMpxcDfk+RiS2jvK0hR0EzmBRnrKuXP0X2b3VNLNaEIbgn6/u2J26iH7+T8hk
7U27Kkp6vvacm82TKI3PbJf/9oHY70PHjZtzFheN6C5HNt8cur4B32v3/Xm476q+
+5MRo2s8+2c9za/0tvrpA2sFZczg7a7ChKg8
-----END CERTIFICATE-----

Code: Select all

Code: Select all

# Notice to Mullvad customers:
# 
# For those of you behind very restrictive firewalls,
# you can use our tunnels on tcp port 443, as well as
# on udp port 53.
client

dev tun

proto udp
#proto udp
#proto tcp

remote openvpn.mullvad.net 1194
#remote openvpn.mullvad.net 443
#remote openvpn.mullvad.net 53
#remote se.mullvad.net # Servers in Sweden
#remote nl.mullvad.net # Servers in the Netherlands
#remote de.mullvad.net # Servers in Germany
#remote us.mullvad.net # Servers in the USA

# Tunnel IPv6 traffic as well as IPv4
#tun-ipv6

# Keep trying indefinitely to resolve the
# host name of the OpenVPN server.  Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite

# Most clients don't need to bind to
# a specific local port number.
nobind

# Try to preserve some state across restarts.
persist-key
persist-tun

# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
comp-lzo

# Set log file verbosity.
verb 3

remote-cert-tls server

ping-restart 60

# Daemonize
service mullvadopenvpn

ping 10

ca ca.crt
cert mullvad.crt
key mullvad.key

crl-verify crl.pem

Code: Select all

# Notice to Mullvad customers:
# 
# Apart from openvpn, you also need to install the
# package "resolvconf", available via apt, e.g.
#
# For those of you behind very restrictive firewalls,
# you can use our tunnels on tcp port 443, as well as
# on udp port 53.
client

dev tun

proto udp
#proto udp
#proto tcp

remote openvpn.mullvad.net 1194
#remote openvpn.mullvad.net 1194
#remote openvpn.mullvad.net 443
#remote openvpn.mullvad.net 53
#remote se.mullvad.net # Servers in Sweden
#remote nl.mullvad.net # Servers in the Netherlands
#remote de.mullvad.net # Servers in Germany
#remote us.mullvad.net # Servers in the USA

# Tunnel IPv6 traffic as well as IPv4
tun-ipv6

# Keep trying indefinitely to resolve the
# host name of the OpenVPN server.  Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite

# Most clients don't need to bind to
# a specific local port number.
nobind

# Try to preserve some state across restarts.
persist-key
persist-tun

# Enable compression on the VPN link.
comp-lzo

# Set log file verbosity.
verb 3

remote-cert-tls server

ping-restart 60

# Allow calling of built-in executables and user-defined scripts.
script-security 2

# Parses DHCP options from openvpn to update resolv.conf
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

ping 10

ca ca.crt
cert mullvad.crt
key mullvad.key

crl-verify crl.pem

Code: Select all

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 3 (0x3)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=NA, ST=None, L=None, O=Mullvad, CN=Mullvad CA/emailAddress=info@mullvad.net
        Validity
            Not Before: Mar 24 16:19:48 2009 GMT
            Not After : Mar 22 16:19:48 2019 GMT
        Subject: C=NA, ST=None, L=None, O=Mullvad, CN=master.mullvad.net/emailAddress=info@mullvad.net....
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:c5:00:39:5d:fe:9b:0c:b7:ff:76:a4:93:bf:26:
                    1b:d6:c8:4a:e5:3c:ce:1c:2c:16:80:a2:61:a6:e9:
                    63:4b:70:a1:80:6f:0e:0c:bb:a9:b6:d1:bd:f5:a0:
                    78:82:09:4d:94:22:aa:77:7c:09:36:42:cd:a5:a6:
                    90:73:27:42:00:31:e4:d4:8b:49:36:65:a3:25:82:
                    b8:26:d7:d1:f5:b5:a9:be:57:93:9d:7c:d6:1c:df:
                    9a:87:81:53:0b:17:81:d1:0d:ca:dc:4d:19:13:fa:
                    11:e6:da:68:eb:81:05:39:e3:1e:3a:3f:fc:e2:64:
                    3c:98:3c:89:a9:42:b3:30:70:57:56:a1:f5:08:b2:
                    75:12:a0:36:93:9d:69:e9:7e:11:71:d9:1c:e8:7d:
                    ec:03:21:11:7a:0a:7a:03:35:ba:b8:b2:0c:3a:6f:
                    57:88:62:45:3d:0c:6c:18:ff:21:49:37:ae:40:78:
                    6d:45:52:29:ac:21:ad:4a:01:61:67:0b:01:c4:ac:
                    b0:88:97:52:ff:cb:3a:21:f0:14:2b:c1:79:8d:79:
                    35:14:fc:9c:3f:6c:c9:62:fc:8c:c7:a8:51:34:75:
                    1c:23:d5:db:b9:44:08:1c:0c:17:2c:21:2a:b4:29:
                    db:15:59:e7:a9:1c:d6:19:19:ef:e4:6b:ea:78:6d:
                    76:8d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                75:8A:14:92:0D:F3:6E:B7:36:4F:8B:4F:15:6C:3F:18:15:90:64:DE
            X509v3 Authority Key Identifier: 
                keyid:E1:63:B4:3E:55:A3:D2:37:5F:DE:3A:91:48:51:4B:20:1A:F2:9B:C5
                DirName:/C=NA/ST=None/L=None/O=Mullvad/CN=Mullvad CA/emailAddress=info@mullvad.net
                serial:84:68:2E:A0:51:2A:BB:D4

            X509v3 Basic Constraints: 
                CA:TRUE
    Signature Algorithm: sha1WithRSAEncryption
        a4:b4:62:3d:cb:7e:57:b3:bd:2a:41:e0:3b:94:d0:4c:08:69:
        8a:b1:73:15:13:20:c9:d7:b0:b6:5d:65:4a:4d:1d:27:cc:ca:
        11:0e:86:fa:65:61:26:39:c2:54:8e:da:eb:78:21:37:0e:c7:
        a4:d2:17:8a:4b:ad:17:84:25:5e:24:0e:9a:81:ff:d1:1b:0e:
        32:9b:f4:81:e0:07:e9:8f:9d:c1:43:7f:40:30:01:07:7c:02:
        c7:c4:9c:05:48:4c:bf:41:69:57:c1:d3:bb:a3:5a:01:17:96:
        b0:c9:00:22:57:2f:84:da:45:33:6e:6c:2b:13:c5:af:75:a7:
        b2:6b:71:6e:13:2c:97:0e:d9:93:da:6d:d9:34:c6:06:7d:0e:
        e2:b8:d2:78:13:79:0f:ac:ac:a8:68:a9:72:73:7a:d8:ab:7b:
        0a:b0:54:b5:f3:ce:29:0d:47:82:0c:b4:d9:20:64:ff:ef:17:
        46:92:de:65:e8:67:ce:3a:92:de:e4:3e:99:73:9f:7a:7c:00:
        72:07:39:78:77:37:62:89:a2:db:24:fd:60:2a:e0:82:57:f6:
        55:94:f6:79:47:19:c9:13:3b:5d:b7:6b:66:14:d4:7d:3c:76:
        75:e9:a3:55:ba:b4:92:30:3b:ad:66:72:0c:39:4b:cc:95:a9:
        bc:06:ef:2b
-----BEGIN CERTIFICATE-----
MIIEQjCCAyqgAwIBAgIBAzANBgkqhkiG9w0BAQUFADBzMQswCQYDVQQGEwJOQTEN
MAsGA1UECBMETm9uZTENMAsGA1UEBxMETm9uZTEQMA4GA1UEChMHTXVsbHZhZDET
MBEGA1UEAxMKTXVsbHZhZCBDQTEfMB0GCSqGSIb3DQEJARYQaW5mb0BtdWxsdmFk
Lm5ldDAeFw0wOTAzMjQxNjE5NDhaFw0xOTAzMjIxNjE5NDhaMHsxCzAJBgNVBAYT
Ak5BMQ0wCwYDVQQIEwROb25lMQ0wCwYDVQQHEwROb25lMRAwDgYDVQQKEwdNdWxs
dmFkMRswGQYDVQQDExJtYXN0ZXIubXVsbHZhZC5uZXQxHzAdBgkqhkiG9w0BCQEW
EGluZm9AbXVsbHZhZC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDFADld/psMt/92pJO/JhvWyErlPM4cLBaAomGm6WNLcKGAbw4Mu6m20b31oHiC
CU2UIqp3fAk2Qs2lppBzJ0IAMeTUi0k2ZaMlgrgm19H1tam+V5OdfNYc35qHgVML
F4HRDcrcTRkT+hHm2mjrgQU54x46P/ziZDyYPImpQrMwcFdWofUIsnUSoDaTnWnp
fhFx2RzofewDIRF6CnoDNbq4sgw6b1eIYkU9DGwY/yFJN65AeG1FUimsIa1KAWFn
CwHErLCIl1L/yzoh8BQrwXmNeTUU/Jw/bMli/IzHqFE0dRwj1du5RAgcDBcsISq0
KdsVWeepHNYZGe/ka+p4bXaNAgMBAAGjgdgwgdUwHQYDVR0OBBYEFHWKFJIN8263
Nk+LTxVsPxgVkGTeMIGlBgNVHSMEgZ0wgZqAFOFjtD5Vo9I3X946kUhRSyAa8pvF
oXekdTBzMQswCQYDVQQGEwJOQTENMAsGA1UECBMETm9uZTENMAsGA1UEBxMETm9u
ZTEQMA4GA1UEChMHTXVsbHZhZDETMBEGA1UEAxMKTXVsbHZhZCBDQTEfMB0GCSqG
SIb3DQEJARYQaW5mb0BtdWxsdmFkLm5ldIIJAIRoLqBRKrvUMAwGA1UdEwQFMAMB
Af8wDQYJKoZIhvcNAQEFBQADggEBAKS0Yj3LflezvSpB4DuU0EwIaYqxcxUTIMnX
sLZdZUpNHSfMyhEOhvplYSY5wlSO2ut4ITcOx6TSF4pLrReEJV4kDpqB/9EbDjKb
9IHgB+mPncFDf0AwAQd8AsfEnAVITL9BaVfB07ujWgEXlrDJACJXL4TaRTNubCsT
xa91p7JrcW4TLJcO2ZPabdk0xgZ9DuK40ngTeQ+srKhoqXJzetirewqwVLXzzikN
R4IMtNkgZP/vF0aS3mXoZ846kt7kPplzn3p8AHIHOXh3N2KJotsk/WAq4IJX9lWU
9nlHGckTO123a2YU1H08dnXpo1W6tJIwO61mcgw5S8yVqbwG7ys=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEQjCCAyqgAwIBAgIJAIRoLqBRKrvUMA0GCSqGSIb3DQEBBQUAMHMxCzAJBgNV
BAYTAk5BMQ0wCwYDVQQIEwROb25lMQ0wCwYDVQQHEwROb25lMRAwDgYDVQQKEwdN
dWxsdmFkMRMwEQYDVQQDEwpNdWxsdmFkIENBMR8wHQYJKoZIhvcNAQkBFhBpbmZv
QG11bGx2YWQubmV0MB4XDTA5MDMyNDA2NDcyNVoXDTE5MDMyMjA2NDcyNVowczEL
MAkGA1UEBhMCTkExDTALBgNVBAgTBE5vbmUxDTALBgNVBAcTBE5vbmUxEDAOBgNV
BAoTB011bGx2YWQxEzARBgNVBAMTCk11bGx2YWQgQ0ExHzAdBgkqhkiG9w0BCQEW
EGluZm9AbXVsbHZhZC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDNNzZOrq+gMaA6wfyWdNFmxlM2OB1czwFgtPiDd9f6F8m6CGYBQog3Q2Wx3yAv
hxt/uchFBCKtYz6Yh59BCxXKfNAQT2uaMC6KAvKFgz0wppi4S8YbWg2KDelNO/Zv
Rb1QT4CBWMbtYzCQZvlJpHr2ZwuXG2OiT477oMyX5Hmf+iT0drmqi+wylRr7CRBs
LBu+fxLZ2LFD5g6MATuL3ql5JLIoVjlSqIgbld74pD4WUnM61HRwFsKoCEjq409Y
QNP1xO7BeaJu3uQvg/HJhXnGZxTatXhqvdCuAPQRppQ4UnkUzxdSTrfgM3hqMony
vX1vy0dX1S8iTQCIeyzAYNObAgMBAAGjgdgwgdUwHQYDVR0OBBYEFOFjtD5Vo9I3
X946kUhRSyAa8pvFMIGlBgNVHSMEgZ0wgZqAFOFjtD5Vo9I3X946kUhRSyAa8pvF
oXekdTBzMQswCQYDVQQGEwJOQTENMAsGA1UECBMETm9uZTENMAsGA1UEBxMETm9u
ZTEQMA4GA1UEChMHTXVsbHZhZDETMBEGA1UEAxMKTXVsbHZhZCBDQTEfMB0GCSqG
SIb3DQEJARYQaW5mb0BtdWxsdmFkLm5ldIIJAIRoLqBRKrvUMAwGA1UdEwQFMAMB
Af8wDQYJKoZIhvcNAQEFBQADggEBAMjMAFPDeFOrQsvMXD/x+CuARwegS2PDZuB5
f1Svw3YDF6cB1jlc0F12nh9SZxaYRwKIlpYoolLCOLoUCLwQJ0gsokxLV7G4gVb8
dzETnNq4HG/QOPwPisjoOCaEmcd0tx1EkyNY0KLqFZTS0VdmDHCn89dDFA/6yuYI
5u04uJs7c/K4qaW7X6ajOOdneqjbtPeVOvx9DWXHxA0xz4Y+/w4laX/OTRD7jySq
K9fLfRliE5zsxzpUr5EWxAnqiABoWL71SiItk5fG8k3MJJ9SVr+YnTHmE7S4KNqu
4wTksvkb0Tmjae1lRSlMd6u2AulAxVcVKAod2QVffhj+hdkYM94=
-----END CERTIFICATE-----

Postby **Pattern_Juggled** » Wed Nov 26, 2014 6:13 pm

Ok this is really tragic. That's the only word I have.

I glanced at these last nite, when they were posted. Something was, right away, not right... but I was trying not to really look at this until later this week. However, it kept nagging at me and finally I came back to look more closely.

Tragic.

The zip file included in the original post includes the following files (plus some other stuff):

The windows conf has the following PKI parameters in it:

Code: Select all

ca ca.crt
cert mullvad.crt
key mullvad.key

That nomenclature is surprising. To me anyhow, having fiddled with these three lines of openvpn parameters waaaaaay more hours than I'd like to admit. Here's the exact lines as quoted from an early (beta) version of cryptostorm's Windows conf's:

Code: Select all

ca ca.crt
cert clientgeneric.crt
key clientgeneric.key
# specification & location of server-verification PKI materials
# for details, see http://pki.cryptostorm.org

There's several stories embedded in this little params snippet. First, the way we chose to do our PKI for cryptostorm is not the default suggested by the OpenVPN documentation; hence the reference to the forum thread (pki.cryptostorm.org) to explain what we're doing, and why. Because in fact, the "clientgeneric.crt" and "clientgeneric.key" are not used in our PKI model. More, they aren't even distributed with the widget, or with any of our other client-side tools. I did generate them, long ago, server-side but they never got used. They're purely vestigial.

Second, the decision to rename those two (purely vestigial) files from the default generated by the easyRSA scripts was debated, heatedly, amoungst our staff. Viciously is really a better description: it got ugly. I wanted them re-named, as it made it clearer that we were not generating individualised client-side private keys; hence "generic." However, renaming them breaks all sorts of stuff in the standard deployments of openvpn, and requires some fiddling with the install to get it settled. Which can be a pain in the ass, across a large deployment. So my decision to start re-naming PKI files that nobody other than us would likely ever notice was.... not popular. This whole kerfuffle was resolved when we realised we could completely remove those "generic" elements of client-side identity validation from our PKI setup. They remained only as vestigial entries in our beta conf's, referring to vestigial files that we never circulated nor used in production.

So that's why the Mullvad naming caught my eye, I think. There's the two client-side files with customised names, but the "ca,crt" file - which is supposed to be the certificate the client uses to validate the server's identity via RSA handshake during the TLS session setup of the control channel of OpenVPN - is left with the default name. My choice, in cryptostorm's pre-launch days, to make a similar eccentric naming selection was unusual... so it was odd to see someone else who had chosen a similar procedure.

But, and here's where tragedy strikes, what happens when we look at those files. Ca.crt is supposed to be a simple ASCII-armoured --certificate textbrick. However, here's what is in the Mullvad ca.crt file:

Code: Select all

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 3 (0x3)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=NA, ST=None, L=None, O=Mullvad, CN=Mullvad CA/emailAddress=info@mullvad.net
        Validity
            Not Before: Mar 24 16:19:48 2009 GMT
            Not After : Mar 22 16:19:48 2019 GMT
        Subject: C=NA, ST=None, L=None, O=Mullvad, CN=master.mullvad.net/emailAddress=info@mullvad.net
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:c5:00:39:5d:fe:9b:0c:b7:ff:76:a4:93:bf:26:
                    1b:d6:c8:4a:e5:3c:ce:1c:2c:16:80:a2:61:a6:e9:
                    63:4b:70:a1:80:6f:0e:0c:bb:a9:b6:d1:bd:f5:a0:
                    78:82:09:4d:94:22:aa:77:7c:09:36:42:cd:a5:a6:
                    90:73:27:42:00:31:e4:d4:8b:49:36:65:a3:25:82:
                    b8:26:d7:d1:f5:b5:a9:be:57:93:9d:7c:d6:1c:df:
                    9a:87:81:53:0b:17:81:d1:0d:ca:dc:4d:19:13:fa:
                    11:e6:da:68:eb:81:05:39:e3:1e:3a:3f:fc:e2:64:
                    3c:98:3c:89:a9:42:b3:30:70:57:56:a1:f5:08:b2:
                    75:12:a0:36:93:9d:69:e9:7e:11:71:d9:1c:e8:7d:
                    ec:03:21:11:7a:0a:7a:03:35:ba:b8:b2:0c:3a:6f:
                    57:88:62:45:3d:0c:6c:18:ff:21:49:37:ae:40:78:
                    6d:45:52:29:ac:21:ad:4a:01:61:67:0b:01:c4:ac:
                    b0:88:97:52:ff:cb:3a:21:f0:14:2b:c1:79:8d:79:
                    35:14:fc:9c:3f:6c:c9:62:fc:8c:c7:a8:51:34:75:
                    1c:23:d5:db:b9:44:08:1c:0c:17:2c:21:2a:b4:29:
                    db:15:59:e7:a9:1c:d6:19:19:ef:e4:6b:ea:78:6d:
                    76:8d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                75:8A:14:92:0D:F3:6E:B7:36:4F:8B:4F:15:6C:3F:18:15:90:64:DE
            X509v3 Authority Key Identifier: 
                keyid:E1:63:B4:3E:55:A3:D2:37:5F:DE:3A:91:48:51:4B:20:1A:F2:9B:C5
                DirName:/C=NA/ST=None/L=None/O=Mullvad/CN=Mullvad CA/emailAddress=info@mullvad.net
                serial:84:68:2E:A0:51:2A:BB:D4

            X509v3 Basic Constraints: 
                CA:TRUE
    Signature Algorithm: sha1WithRSAEncryption
        a4:b4:62:3d:cb:7e:57:b3:bd:2a:41:e0:3b:94:d0:4c:08:69:
        8a:b1:73:15:13:20:c9:d7:b0:b6:5d:65:4a:4d:1d:27:cc:ca:
        11:0e:86:fa:65:61:26:39:c2:54:8e:da:eb:78:21:37:0e:c7:
        a4:d2:17:8a:4b:ad:17:84:25:5e:24:0e:9a:81:ff:d1:1b:0e:
        32:9b:f4:81:e0:07:e9:8f:9d:c1:43:7f:40:30:01:07:7c:02:
        c7:c4:9c:05:48:4c:bf:41:69:57:c1:d3:bb:a3:5a:01:17:96:
        b0:c9:00:22:57:2f:84:da:45:33:6e:6c:2b:13:c5:af:75:a7:
        b2:6b:71:6e:13:2c:97:0e:d9:93:da:6d:d9:34:c6:06:7d:0e:
        e2:b8:d2:78:13:79:0f:ac:ac:a8:68:a9:72:73:7a:d8:ab:7b:
        0a:b0:54:b5:f3:ce:29:0d:47:82:0c:b4:d9:20:64:ff:ef:17:
        46:92:de:65:e8:67:ce:3a:92:de:e4:3e:99:73:9f:7a:7c:00:
        72:07:39:78:77:37:62:89:a2:db:24:fd:60:2a:e0:82:57:f6:
        55:94:f6:79:47:19:c9:13:3b:5d:b7:6b:66:14:d4:7d:3c:76:
        75:e9:a3:55:ba:b4:92:30:3b:ad:66:72:0c:39:4b:cc:95:a9:
        bc:06:ef:2b
-----BEGIN CERTIFICATE-----
MIIEQjCCAyqgAwIBAgIBAzANBgkqhkiG9w0BAQUFADBzMQswCQYDVQQGEwJOQTEN
MAsGA1UECBMETm9uZTENMAsGA1UEBxMETm9uZTEQMA4GA1UEChMHTXVsbHZhZDET
MBEGA1UEAxMKTXVsbHZhZCBDQTEfMB0GCSqGSIb3DQEJARYQaW5mb0BtdWxsdmFk
Lm5ldDAeFw0wOTAzMjQxNjE5NDhaFw0xOTAzMjIxNjE5NDhaMHsxCzAJBgNVBAYT
Ak5BMQ0wCwYDVQQIEwROb25lMQ0wCwYDVQQHEwROb25lMRAwDgYDVQQKEwdNdWxs
dmFkMRswGQYDVQQDExJtYXN0ZXIubXVsbHZhZC5uZXQxHzAdBgkqhkiG9w0BCQEW
EGluZm9AbXVsbHZhZC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDFADld/psMt/92pJO/JhvWyErlPM4cLBaAomGm6WNLcKGAbw4Mu6m20b31oHiC
CU2UIqp3fAk2Qs2lppBzJ0IAMeTUi0k2ZaMlgrgm19H1tam+V5OdfNYc35qHgVML
F4HRDcrcTRkT+hHm2mjrgQU54x46P/ziZDyYPImpQrMwcFdWofUIsnUSoDaTnWnp
fhFx2RzofewDIRF6CnoDNbq4sgw6b1eIYkU9DGwY/yFJN65AeG1FUimsIa1KAWFn
CwHErLCIl1L/yzoh8BQrwXmNeTUU/Jw/bMli/IzHqFE0dRwj1du5RAgcDBcsISq0
KdsVWeepHNYZGe/ka+p4bXaNAgMBAAGjgdgwgdUwHQYDVR0OBBYEFHWKFJIN8263
Nk+LTxVsPxgVkGTeMIGlBgNVHSMEgZ0wgZqAFOFjtD5Vo9I3X946kUhRSyAa8pvF
oXekdTBzMQswCQYDVQQGEwJOQTENMAsGA1UECBMETm9uZTENMAsGA1UEBxMETm9u
ZTEQMA4GA1UEChMHTXVsbHZhZDETMBEGA1UEAxMKTXVsbHZhZCBDQTEfMB0GCSqG
SIb3DQEJARYQaW5mb0BtdWxsdmFkLm5ldIIJAIRoLqBRKrvUMAwGA1UdEwQFMAMB
Af8wDQYJKoZIhvcNAQEFBQADggEBAKS0Yj3LflezvSpB4DuU0EwIaYqxcxUTIMnX
sLZdZUpNHSfMyhEOhvplYSY5wlSO2ut4ITcOx6TSF4pLrReEJV4kDpqB/9EbDjKb
9IHgB+mPncFDf0AwAQd8AsfEnAVITL9BaVfB07ujWgEXlrDJACJXL4TaRTNubCsT
xa91p7JrcW4TLJcO2ZPabdk0xgZ9DuK40ngTeQ+srKhoqXJzetirewqwVLXzzikN
R4IMtNkgZP/vF0aS3mXoZ846kt7kPplzn3p8AHIHOXh3N2KJotsk/WAq4IJX9lWU
9nlHGckTO123a2YU1H08dnXpo1W6tJIwO61mcgw5S8yVqbwG7ys=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEQjCCAyqgAwIBAgIJAIRoLqBRKrvUMA0GCSqGSIb3DQEBBQUAMHMxCzAJBgNV
BAYTAk5BMQ0wCwYDVQQIEwROb25lMQ0wCwYDVQQHEwROb25lMRAwDgYDVQQKEwdN
dWxsdmFkMRMwEQYDVQQDEwpNdWxsdmFkIENBMR8wHQYJKoZIhvcNAQkBFhBpbmZv
QG11bGx2YWQubmV0MB4XDTA5MDMyNDA2NDcyNVoXDTE5MDMyMjA2NDcyNVowczEL
MAkGA1UEBhMCTkExDTALBgNVBAgTBE5vbmUxDTALBgNVBAcTBE5vbmUxEDAOBgNV
BAoTB011bGx2YWQxEzARBgNVBAMTCk11bGx2YWQgQ0ExHzAdBgkqhkiG9w0BCQEW
EGluZm9AbXVsbHZhZC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDNNzZOrq+gMaA6wfyWdNFmxlM2OB1czwFgtPiDd9f6F8m6CGYBQog3Q2Wx3yAv
hxt/uchFBCKtYz6Yh59BCxXKfNAQT2uaMC6KAvKFgz0wppi4S8YbWg2KDelNO/Zv
Rb1QT4CBWMbtYzCQZvlJpHr2ZwuXG2OiT477oMyX5Hmf+iT0drmqi+wylRr7CRBs
LBu+fxLZ2LFD5g6MATuL3ql5JLIoVjlSqIgbld74pD4WUnM61HRwFsKoCEjq409Y
QNP1xO7BeaJu3uQvg/HJhXnGZxTatXhqvdCuAPQRppQ4UnkUzxdSTrfgM3hqMony
vX1vy0dX1S8iTQCIeyzAYNObAgMBAAGjgdgwgdUwHQYDVR0OBBYEFOFjtD5Vo9I3
X946kUhRSyAa8pvFMIGlBgNVHSMEgZ0wgZqAFOFjtD5Vo9I3X946kUhRSyAa8pvF
oXekdTBzMQswCQYDVQQGEwJOQTENMAsGA1UECBMETm9uZTENMAsGA1UEBxMETm9u
ZTEQMA4GA1UEChMHTXVsbHZhZDETMBEGA1UEAxMKTXVsbHZhZCBDQTEfMB0GCSqG
SIb3DQEJARYQaW5mb0BtdWxsdmFkLm5ldIIJAIRoLqBRKrvUMAwGA1UdEwQFMAMB
Af8wDQYJKoZIhvcNAQEFBQADggEBAMjMAFPDeFOrQsvMXD/x+CuARwegS2PDZuB5
f1Svw3YDF6cB1jlc0F12nh9SZxaYRwKIlpYoolLCOLoUCLwQJ0gsokxLV7G4gVb8
dzETnNq4HG/QOPwPisjoOCaEmcd0tx1EkyNY0KLqFZTS0VdmDHCn89dDFA/6yuYI
5u04uJs7c/K4qaW7X6ajOOdneqjbtPeVOvx9DWXHxA0xz4Y+/w4laX/OTRD7jySq
K9fLfRliE5zsxzpUr5EWxAnqiABoWL71SiItk5fG8k3MJJ9SVr+YnTHmE7S4KNqu
4wTksvkb0Tmjae1lRSlMd6u2AulAxVcVKAod2QVffhj+hdkYM94=
-----END CERTIFICATE-----

Yikes. That's the entire server-side certificate as well as the PEM-encoded client-side version of it (the first --CERTIFICATE textblock) used to validate the server. The good news is there's no server key to correspond to that server-side certificate. I checked. By the way, you can verify that the first --CERTIFICATE block is derived from the cert materials above it using this online tool, or from local terminal if you prefer. CN is listed as master.mullvad.net.

So if that's the server-side certificate, plus client-side cert validation block... so what's that second --CERTIFICATE textblock? It's a PEM-encoded version of something..,. but what? It's not related to the server certificate included (incorrectly, btw) in ca.crt.

Here's where things get tragic.

That second --CERTIFICATE textblock is actually the PEM-encoded version of mullvad.crt. That's easy enough to confirm yourself. So... oh no. What does that make mullvad.key? Gold star for those who have already guessed...

It's the server-side private key corresponding to mullvad.crt. Confirm for yourself using this, or via local terminal.

Here's some text that explains what that key is:

Your private key is intended to remain on the server. While we try to make this process as secure as possible by using SSL to encrypt the key when it is sent to the server, for complete security, we recommend that you manually check the modulus of the private key on your server...

That private key, in other words, is NEVER supposed to leave the server that generated it. For it to be disclosed is a massive - tragic - breach of the entire security of the VPN itself, top to bottom.

With that server-side key, a passive attacker has the easiest MiTM attack ever. Using one of several freely-available, well-developed MiTM toolsets, you simply tell the client that you are the "server" it is trying to connect to. You have the cryptographic materials to do so, right in these files. Then you have all of your target's plaintext traffic, running through your cloned "Mullvad" server.

To put this in perspective, the entire attack method of the "heartbleed" bug, this summer, on openvpn-based systems involved the possibility of these server-side key materials getting leaked via heartbleed's memory sloppiness. That was the worst-case risk of heartbleed, for VPN services. Indeed, Mullvad has a blog entry talking about hearbleed, and the risk of disclosing private keys:

Mullvad is distributing those key materials with every installer they ship out.

The best I can guess, whoever did these Mullvad materials just didn't understand - at all - how PKI works. They tried with the default materials generated by easyRSA, and got ca.crt... but something wasn't working. So they re-generated (using a new CN), and renamed the new materials mullvad.crt and mullvad.key. Perhaps they looked at cryptostorm's publicly-published conf's which include my quirky - but never used in production - vestigial naming convention and figured somehow this was worth cloning. Sadly, not only did they not notice we don't use those files, they didn't even clone properly (if that's what happened). Because, somehow, they ended up pasting the PEM-versioned ca.crt of the second set of PKI materials into the ca.crt file from the first ones. What a mess. :eh:

This leaves a bit of a challenge for the openvpn daemon to parse, at runtime. You've got a mishmash of PKI materials referenced from within the conf, and included in the installer files... my initial read is that the master.mullvad.net cert will be ignored - it doesn't match the directives in the conf - and the second PEM-block --CERTIFICATE is parsed as matching the mullvad.crt server-side PEM-block in mullvad.crt. What openvpn makes of the server-side key being included in mullvad.key I honestly don't know without further wiresharking...

- - -

Look, everyone makes mistakes. I get that. I've made them, our team at cryptostorm has made them... that's life. One corrects them quickly, works to avoid them in the first place, and generally acknowledges that being in the security industry means mistakes are not a laughing matter. But this stuff, publishing private keys... these aren't just "mistakes." Nor are they naive crypto choices that a more experienced practitioner might rightfully question (and speaking of that, Mullvad fails to specify any cipher suites in their config files, which means rollback version attacks to useless cipher suites is easy to do... although basically unnecessary, since they publish the server key anyway).

These "mistakes" are horrible, sloppy, painful examples of amateurs at work. I'm sorry, but there's no nice way to say that. This isn't some small thing, nor is it a one-off issue (bad day at the office, etc.). These materials are being pumped out to the public day in and day out, even as paying customers of Mullvad trust this "privacy service" to keep them safe from surveillance. This "encryption" is utterly worthless because of the key publication; that Mullvad also supports PPTP - a worthless VPN protocol - is doubly tragic.

Once again, this is a "VPN service" that gets high marks from all sorts of review and tech websites... apparently nobody bothered to actually look at the files being included with the installer. That's also tragic. And indefensible.

Torrentfreak includes them in the "VPN providers that take privacy seriously" list. And here's Mullvad's reply to a question about their encryption:

We use OpenVPN. We also provide PPTP because some people want it but we strongly recommend against it. Encryption algorithms and key lengths are important but often get way too much attention at the expense of other important but harder to measure things such as leaks and computer security.

Yeah... "leaks and computer security." Sure guys, I think you're spot-on in your sage comments about encryption algorithms being unimportant... given that you're publishing private keys anyhow.

I know I sound like I'm being a dick to Mullvad, and I regret that. I've nothing against the guys running this service - hell they are obviously good marketers as they've convinced lots of folks to list them as a solid, reliable, professional privacy service. That, in practice, they can't even get a default openvpn installation running without turning the PKI framework into a dog's breakfast is... tragic.

Cheers,

~ pj

edited to add: a look at the certificate revocation materials included in the installer (crl.pem), confirms that the cert revoked as a result of heartbleed (and mentioned in the Mullvad blog post, above) is master.mullvad.net - the cert that does not have it's private key published in this installer. That's confirmation that the private key & cert materials included are, in fact, in production and not left over from pre-heartbleed. Here's the PEM textblock:

Code: Select all

Which unpacks (with errors) to the following human-readable version (note "PrintableString 'master.mullvad.net'"):

Code: Select all

   0 1365: SEQUENCE {
   4 1085:   SEQUENCE {
   8   13:     SEQUENCE {
  10    9:       OBJECT IDENTIFIER sha1WithRSAEncryption (1 2 840 113549 1 1 5)
  21    0:       NULL
         :       }
  23  123:     SEQUENCE {
  25   11:       SET {
  27    9:         SEQUENCE {
  29    3:           OBJECT IDENTIFIER countryName (2 5 4 6)
  34    2:           PrintableString 'NA'
         :           }
         :         }
  38   13:       SET {
  40   11:         SEQUENCE {
  42    3:           OBJECT IDENTIFIER stateOrProvinceName (2 5 4 8)
  47    4:           PrintableString 'None'
         :           }
         :         }
  53   13:       SET {
  55   11:         SEQUENCE {
  57    3:           OBJECT IDENTIFIER localityName (2 5 4 7)
  62    4:           PrintableString 'None'
         :           }
         :         }
  68   16:       SET {
  70   14:         SEQUENCE {
  72    3:           OBJECT IDENTIFIER organizationName (2 5 4 10)
  77    7:           PrintableString 'Mullvad'
         :           }
         :         }
  86   27:       SET {
  88   25:         SEQUENCE {
  90    3:           OBJECT IDENTIFIER commonName (2 5 4 3)
  95   18:           PrintableString 'master.mullvad.net'
         :           }
         :         }
 115   31:       SET {
 117   29:         SEQUENCE {
 119    9:           OBJECT IDENTIFIER emailAddress (1 2 840 113549 1 9 1)
 130   16:           IA5String 'info@mullvad.net'
         :           }
         :         }
         :       }
 148   13:     UTCTime 08/04/2014 21:52:26 GMT
 163   13:     UTCTime 05/04/2024 21:52:26 GMT
 178  911:     SEQUENCE {
 182   18:       SEQUENCE {
 184    1:         INTEGER 1
 187   13:         UTCTime 08/04/2014 21:35:02 GMT
         :         }
 202   18:       SEQUENCE {
 204    1:         INTEGER 3
 207   13:         UTCTime 08/04/2014 21:35:09 GMT
         :         }
 222   18:       SEQUENCE {
 224    1:         INTEGER 41
 227   13:         UTCTime 08/04/2014 21:35:10 GMT
         :         }
 242   19:       SEQUENCE {
 244    2:         INTEGER 3499
 248   13:         UTCTime 08/04/2014 21:35:14 GMT
         :         }
 263   19:       SEQUENCE {
 265    2:         INTEGER 3500
 269   13:         UTCTime 08/04/2014 21:35:15 GMT
         :         }
 284   19:       SEQUENCE {
 286    2:         INTEGER 3501
 290   13:         UTCTime 08/04/2014 21:35:19 GMT
         :         }
 305   19:       SEQUENCE {
 307    2:         INTEGER 3870
 311   13:         UTCTime 08/04/2014 21:35:20 GMT
         :         }
 326   19:       SEQUENCE {
 328    2:         INTEGER 6939
 332   13:         UTCTime 08/04/2014 21:35:24 GMT
         :         }
 347   19:       SEQUENCE {
 349    2:         INTEGER 15870
 353   13:         UTCTime 08/04/2014 21:35:25 GMT
         :         }
 368   19:       SEQUENCE {
 370    2:         INTEGER 19125
 374   13:         UTCTime 08/04/2014 21:35:30 GMT
         :         }
 389   20:       SEQUENCE {
 391    3:         INTEGER 112343
 396   13:         UTCTime 08/04/2014 21:35:32 GMT
         :         }
 411   20:       SEQUENCE {
 413    3:         INTEGER 433744
 418   13:         UTCTime 08/04/2014 21:35:35 GMT
         :         }
 433   20:       SEQUENCE {
 435    3:         INTEGER 433749
 440   13:         UTCTime 08/04/2014 21:35:39 GMT
         :         }
 455   20:       SEQUENCE {
 457    3:         INTEGER 661395
 462   13:         UTCTime 08/04/2014 16:08:41 GMT
         :         }
 477   20:       SEQUENCE {
 479    3:         INTEGER 683788
 484   13:         UTCTime 08/04/2014 16:09:43 GMT
         :         }
 499   20:       SEQUENCE {
 501    3:         INTEGER 776759
 506   13:         UTCTime 08/04/2014 21:35:42 GMT
         :         }
 521   20:       SEQUENCE {
 523    3:         INTEGER 796616
 528   13:         UTCTime 08/04/2014 17:55:34 GMT
         :         }
 543   20:       SEQUENCE {
 545    3:         INTEGER 797482
 550   13:         UTCTime 08/04/2014 17:57:26 GMT
         :         }
 565   20:       SEQUENCE {
 567    3:         INTEGER 800097
 572   13:         UTCTime 08/04/2014 21:35:51 GMT
         :         }
 587   20:       SEQUENCE {
 589    3:         INTEGER 800098
 594   13:         UTCTime 08/04/2014 17:58:36 GMT
         :         }
 609   20:       SEQUENCE {
 611    3:         INTEGER 825221
 616   13:         UTCTime 08/04/2014 18:00:33 GMT
         :         }
 631   20:       SEQUENCE {
 633    3:         INTEGER 849877
 638   13:         UTCTime 08/04/2014 21:35:57 GMT
         :         }
 653   20:       SEQUENCE {
 655    3:         INTEGER 849878
 660   13:         UTCTime 08/04/2014 17:57:44 GMT
         :         }
 675   20:       SEQUENCE {
 677    3:         INTEGER 849879
 682   13:         UTCTime 08/04/2014 21:35:58 GMT
         :         }
 697   20:       SEQUENCE {
 699    3:         INTEGER 849891
 704   13:         UTCTime 08/04/2014 17:58:21 GMT
         :         }
 719   20:       SEQUENCE {
 721    3:         INTEGER 849892
 726   13:         UTCTime 08/04/2014 17:58:58 GMT
         :         }
 741   20:       SEQUENCE {
 743    3:         INTEGER 849893
 748   13:         UTCTime 08/04/2014 18:02:19 GMT
         :         }
 763   20:       SEQUENCE {
 765    3:         INTEGER 857201
 770   13:         UTCTime 08/04/2014 21:35:41 GMT
         :         }
 785   20:       SEQUENCE {
 787    3:         INTEGER 857227
 792   13:         UTCTime 08/04/2014 17:59:08 GMT
         :         }
 807   20:       SEQUENCE {
 809    3:         INTEGER 869756
 814   13:         UTCTime 08/04/2014 21:36:05 GMT
         :         }
 829   20:       SEQUENCE {
 831    3:         INTEGER 872807
 836   13:         UTCTime 08/04/2014 21:36:06 GMT
         :         }
 851   20:       SEQUENCE {
 853    3:         INTEGER 872808
 858   13:         UTCTime 08/04/2014 21:36:08 GMT
         :         }
 873   20:       SEQUENCE {
 875    3:         INTEGER 872812
 880   13:         UTCTime 08/04/2014 21:36:12 GMT
         :         }
 895   20:       SEQUENCE {
 897    3:         INTEGER 907274
 902   13:         UTCTime 08/04/2014 21:35:50 GMT
         :         }
 917   20:       SEQUENCE {
 919    3:         INTEGER 907275
 924   13:         UTCTime 08/04/2014 18:01:07 GMT
         :         }
 939   20:       SEQUENCE {
 941    3:         INTEGER 952031
 946   13:         UTCTime 08/04/2014 21:36:16 GMT
         :         }
 961   20:       SEQUENCE {
 963    3:         INTEGER 955036
 968   13:         UTCTime 08/04/2014 15:16:58 GMT
         :         }
 983   20:       SEQUENCE {
 985    3:         INTEGER 955037
 990   13:         UTCTime 08/04/2014 16:09:51 GMT
         :         }
1005   20:       SEQUENCE {
1007    3:         INTEGER 967514
1012   13:         UTCTime 08/04/2014 18:00:46 GMT
         :         }
1027   20:       SEQUENCE {
1029    3:         INTEGER 988225
1034   13:         UTCTime 08/04/2014 21:36:17 GMT
         :         }
1049   20:       SEQUENCE {
1051    3:         INTEGER 992911
1056   13:         UTCTime 08/04/2014 20:40:56 GMT
         :         }
1071   20:       SEQUENCE {
1073    3:         INTEGER 1000407
1078   13:         UTCTime 08/04/2014 18:02:32 GMT
         :         }
         :       }
         :     }
1093   13:   SEQUENCE {
1095    9:     OBJECT IDENTIFIER sha1WithRSAEncryption (1 2 840 113549 1 1 5)
1106    0:     NULL
         :     }
1108  257:   BIT STRING
         :     BD BD 18 FE 7B 87 00 31 85 45 5D 57 1B 50 59 35
         :     21 0D 6F BC 6C 4E B0 9D F2 7D 35 D6 3D 62 FD 1A
         :     5C 6B DE E2 BE 17 66 E2 05 59 E0 58 E6 E1 A5 3B
         :     1E 3C BD 75 00 EE C2 D4 0D 70 5C 5B D2 C6 43 63
         :     CC 51 DA 23 6B 07 2E 2B 30 21 D2 D2 F8 9E 77 44
         :     10 23 77 BB C6 46 1F 78 83 C7 4D C0 C8 D4 85 CC
         :     A3 B0 F5 C1 B9 B2 AF 93 1B 4E 70 32 C7 6B B9 5E
         :     B0 1F 47 50 BE E7 B3 69 40 6A DD 38 AD B1 4F 04
         :             [ Another 128 bytes skipped ]
         :   }

Mullvad · Postby **Mullvad** » Thu Nov 27, 2014 2:03 am

No server key is distributed with the configuration package. The only key present (mullvad.key) is the private key for the client certificate (mullvad.crt). The client certificate is not included in the certificate authority file (ca.crt), as you claim it is.

Judging by the screenshot you simply copied-and-pasted the wrong certificate into the online tool. The client certificate was used instead of the one from the certificate authority file. Of course the client key matches its own certificate.

Even though no actual vulnerability was published, it is still unfortunate that you chose not to practice responsible disclosure. Had your claims been true you would have subjected our users to unnecessary risk by not contacting us. We still haven't received any notice from you.

We are competitors but we are also colleagues fighting against a common threat. When we find potential vulnerabilities (such as OpenVPN's vulnerability to Shellshock or Heartbleed) that affect other VPN services we warn them first if appropriate.

Sincerely, Mullvad.

Postby **Pattern_Juggled** » Thu Nov 27, 2014 3:01 am

Mullvad wrote:No server key is distributed with the configuration package. The only key present (mullvad.key) is the private key for the client certificate (mullvad.crt). The client certificate is not included in the certificate authority file (ca.crt), as you claim it is.

Here is the contents of the file "ca.crt," verbatim:

Certificate:
Data:
Version: 3 (0x2)
Serial Number: 3 (0x3)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=NA, ST=None, L=None, O=Mullvad, CN=Mullvad CA/emailAddress=info@mullvad.net
Validity
Not Before: Mar 24 16:19:48 2009 GMT
Not After : Mar 22 16:19:48 2019 GMT
Subject: C=NA, ST=None, L=None, O=Mullvad, CN=master.mullvad.net/emailAddress=info@mullvad.net..
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:c5:00:39:5d:fe:9b:0c:b7:ff:76:a4:93:bf:26:
1b:d6:c8:4a:e5:3c:ce:1c:2c:16:80:a2:61:a6:e9:
63:4b:70:a1:80:6f:0e:0c:bb:a9:b6:d1:bd:f5:a0:
78:82:09:4d:94:22:aa:77:7c:09:36:42:cd:a5:a6:
90:73:27:42:00:31:e4:d4:8b:49:36:65:a3:25:82:
b8:26:d7:d1:f5:b5:a9:be:57:93:9d:7c:d6:1c:df:
9a:87:81:53:0b:17:81:d1:0d:ca:dc:4d:19:13:fa:
11:e6:da:68:eb:81:05:39:e3:1e:3a:3f:fc:e2:64:
3c:98:3c:89:a9:42:b3:30:70:57:56:a1:f5:08:b2:
75:12:a0:36:93:9d:69:e9:7e:11:71:d9:1c:e8:7d:
ec:03:21:11:7a:0a:7a:03:35:ba:b8:b2:0c:3a:6f:
57:88:62:45:3d:0c:6c:18:ff:21:49:37:ae:40:78:
6d:45:52:29:ac:21:ad:4a:01:61:67:0b:01:c4:ac:
b0:88:97:52:ff:cb:3a:21:f0:14:2b:c1:79:8d:79:
35:14:fc:9c:3f:6c:c9:62:fc:8c:c7:a8:51:34:75:
1c:23:d5:db:b9:44:08:1c:0c:17:2c:21:2a:b4:29:
db:15:59:e7:a9:1c:d6:19:19:ef:e4:6b:ea:78:6d:
76:8d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
75:8A:14:92:0D:F3:6E:B7:36:4F:8B:4F:15:6C:3F:18:15:90:64:DE
X509v3 Authority Key Identifier:
keyid:E1:63:B4:3E:55:A3:D2:37:5F:DE:3A:91:48:51:4B:20:1A:F2:9B:C5
DirName:/C=NA/ST=None/L=None/O=Mullvad/CN=Mullvad CA/emailAddress=info@mullvad.net
serial:84:68:2E:A0:51:2A:BB:D4

X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha1WithRSAEncryption
a4:b4:62:3d:cb:7e:57:b3:bd:2a:41:e0:3b:94:d0:4c:08:69:
8a:b1:73:15:13:20:c9:d7:b0:b6:5d:65:4a:4d:1d:27:cc:ca:
11:0e:86:fa:65:61:26:39:c2:54:8e:da:eb:78:21:37:0e:c7:
a4:d2:17:8a:4b:ad:17:84:25:5e:24:0e:9a:81:ff:d1:1b:0e:
32:9b:f4:81:e0:07:e9:8f:9d:c1:43:7f:40:30:01:07:7c:02:
c7:c4:9c:05:48:4c:bf:41:69:57:c1:d3:bb:a3:5a:01:17:96:
b0:c9:00:22:57:2f:84:da:45:33:6e:6c:2b:13:c5:af:75:a7:
b2:6b:71:6e:13:2c:97:0e:d9:93:da:6d:d9:34:c6:06:7d:0e:
e2:b8:d2:78:13:79:0f:ac:ac:a8:68:a9:72:73:7a:d8:ab:7b:
0a:b0:54:b5:f3:ce:29:0d:47:82:0c:b4:d9:20:64:ff:ef:17:
46:92:de:65:e8:67:ce:3a:92:de:e4:3e:99:73:9f:7a:7c:00:
72:07:39:78:77:37:62:89:a2:db:24:fd:60:2a:e0:82:57:f6:
55:94:f6:79:47:19:c9:13:3b:5d:b7:6b:66:14:d4:7d:3c:76:
75:e9:a3:55:ba:b4:92:30:3b:ad:66:72:0c:39:4b:cc:95:a9:
bc:06:ef:2b
-----BEGIN CERTIFICATE-----
MIIEQjCCAyqgAwIBAgIBAzANBgkqhkiG9w0BAQUFADBzMQswCQYDVQQGEwJOQTEN
MAsGA1UECBMETm9uZTENMAsGA1UEBxMETm9uZTEQMA4GA1UEChMHTXVsbHZhZDET
MBEGA1UEAxMKTXVsbHZhZCBDQTEfMB0GCSqGSIb3DQEJARYQaW5mb0BtdWxsdmFk
Lm5ldDAeFw0wOTAzMjQxNjE5NDhaFw0xOTAzMjIxNjE5NDhaMHsxCzAJBgNVBAYT
Ak5BMQ0wCwYDVQQIEwROb25lMQ0wCwYDVQQHEwROb25lMRAwDgYDVQQKEwdNdWxs
dmFkMRswGQYDVQQDExJtYXN0ZXIubXVsbHZhZC5uZXQxHzAdBgkqhkiG9w0BCQEW
EGluZm9AbXVsbHZhZC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDFADld/psMt/92pJO/JhvWyErlPM4cLBaAomGm6WNLcKGAbw4Mu6m20b31oHiC
CU2UIqp3fAk2Qs2lppBzJ0IAMeTUi0k2ZaMlgrgm19H1tam+V5OdfNYc35qHgVML
F4HRDcrcTRkT+hHm2mjrgQU54x46P/ziZDyYPImpQrMwcFdWofUIsnUSoDaTnWnp
fhFx2RzofewDIRF6CnoDNbq4sgw6b1eIYkU9DGwY/yFJN65AeG1FUimsIa1KAWFn
CwHErLCIl1L/yzoh8BQrwXmNeTUU/Jw/bMli/IzHqFE0dRwj1du5RAgcDBcsISq0
KdsVWeepHNYZGe/ka+p4bXaNAgMBAAGjgdgwgdUwHQYDVR0OBBYEFHWKFJIN8263
Nk+LTxVsPxgVkGTeMIGlBgNVHSMEgZ0wgZqAFOFjtD5Vo9I3X946kUhRSyAa8pvF
oXekdTBzMQswCQYDVQQGEwJOQTENMAsGA1UECBMETm9uZTENMAsGA1UEBxMETm9u
ZTEQMA4GA1UEChMHTXVsbHZhZDETMBEGA1UEAxMKTXVsbHZhZCBDQTEfMB0GCSqG
SIb3DQEJARYQaW5mb0BtdWxsdmFkLm5ldIIJAIRoLqBRKrvUMAwGA1UdEwQFMAMB
Af8wDQYJKoZIhvcNAQEFBQADggEBAKS0Yj3LflezvSpB4DuU0EwIaYqxcxUTIMnX
sLZdZUpNHSfMyhEOhvplYSY5wlSO2ut4ITcOx6TSF4pLrReEJV4kDpqB/9EbDjKb
9IHgB+mPncFDf0AwAQd8AsfEnAVITL9BaVfB07ujWgEXlrDJACJXL4TaRTNubCsT
xa91p7JrcW4TLJcO2ZPabdk0xgZ9DuK40ngTeQ+srKhoqXJzetirewqwVLXzzikN
R4IMtNkgZP/vF0aS3mXoZ846kt7kPplzn3p8AHIHOXh3N2KJotsk/WAq4IJX9lWU
9nlHGckTO123a2YU1H08dnXpo1W6tJIwO61mcgw5S8yVqbwG7ys=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEQjCCAyqgAwIBAgIJAIRoLqBRKrvUMA0GCSqGSIb3DQEBBQUAMHMxCzAJBgNV
BAYTAk5BMQ0wCwYDVQQIEwROb25lMQ0wCwYDVQQHEwROb25lMRAwDgYDVQQKEwdN
dWxsdmFkMRMwEQYDVQQDEwpNdWxsdmFkIENBMR8wHQYJKoZIhvcNAQkBFhBpbmZv
QG11bGx2YWQubmV0MB4XDTA5MDMyNDA2NDcyNVoXDTE5MDMyMjA2NDcyNVowczEL
MAkGA1UEBhMCTkExDTALBgNVBAgTBE5vbmUxDTALBgNVBAcTBE5vbmUxEDAOBgNV
BAoTB011bGx2YWQxEzARBgNVBAMTCk11bGx2YWQgQ0ExHzAdBgkqhkiG9w0BCQEW
EGluZm9AbXVsbHZhZC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDNNzZOrq+gMaA6wfyWdNFmxlM2OB1czwFgtPiDd9f6F8m6CGYBQog3Q2Wx3yAv
hxt/uchFBCKtYz6Yh59BCxXKfNAQT2uaMC6KAvKFgz0wppi4S8YbWg2KDelNO/Zv
Rb1QT4CBWMbtYzCQZvlJpHr2ZwuXG2OiT477oMyX5Hmf+iT0drmqi+wylRr7CRBs
LBu+fxLZ2LFD5g6MATuL3ql5JLIoVjlSqIgbld74pD4WUnM61HRwFsKoCEjq409Y
QNP1xO7BeaJu3uQvg/HJhXnGZxTatXhqvdCuAPQRppQ4UnkUzxdSTrfgM3hqMony
vX1vy0dX1S8iTQCIeyzAYNObAgMBAAGjgdgwgdUwHQYDVR0OBBYEFOFjtD5Vo9I3
X946kUhRSyAa8pvFMIGlBgNVHSMEgZ0wgZqAFOFjtD5Vo9I3X946kUhRSyAa8pvF
oXekdTBzMQswCQYDVQQGEwJOQTENMAsGA1UECBMETm9uZTENMAsGA1UEBxMETm9u
ZTEQMA4GA1UEChMHTXVsbHZhZDETMBEGA1UEAxMKTXVsbHZhZCBDQTEfMB0GCSqG
SIb3DQEJARYQaW5mb0BtdWxsdmFkLm5ldIIJAIRoLqBRKrvUMAwGA1UdEwQFMAMB
Af8wDQYJKoZIhvcNAQEFBQADggEBAMjMAFPDeFOrQsvMXD/x+CuARwegS2PDZuB5
f1Svw3YDF6cB1jlc0F12nh9SZxaYRwKIlpYoolLCOLoUCLwQJ0gsokxLV7G4gVb8
dzETnNq4HG/QOPwPisjoOCaEmcd0tx1EkyNY0KLqFZTS0VdmDHCn89dDFA/6yuYI
5u04uJs7c/K4qaW7X6ajOOdneqjbtPeVOvx9DWXHxA0xz4Y+/w4laX/OTRD7jySq
K9fLfRliE5zsxzpUr5EWxAnqiABoWL71SiItk5fG8k3MJJ9SVr+YnTHmE7S4KNqu
4wTksvkb0Tmjae1lRSlMd6u2AulAxVcVKAod2QVffhj+hdkYM94=
-----END CERTIFICATE-----

There are actually three "certificates" in this file. Two are different versions of the revoked pre-heartbleed cert; the third is the PEM-encoded version of the certificate in human-readable form that is included in the file "mullvad.crt."

Let's go through these three "certs" one by one. Here's the PEM text from mullvad.crt:

-----BEGIN CERTIFICATE-----
MIIENzCCAx+gAwIBAgIDEn7VMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAk5B
MQ0wCwYDVQQIEwROb25lMQ0wCwYDVQQHEwROb25lMRAwDgYDVQQKEwdNdWxsdmFk
MRswGQYDVQQDExJtYXN0ZXIubXVsbHZhZC5uZXQxHzAdBgkqhkiG9w0BCQEWEGlu
Zm9AbXVsbHZhZC5uZXQwHhcNMDkwMTAxMDAwMDAwWhcNMjQxMTIzMDUxNTMxWjAe
MRwwGgYDVQQDExNNdWxsdmFkMTc5MzQ4NDUzNTQxMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAt2hKCUauSkejAUfMJll1zByoH4055k8OfcWbndDuD8xz
CZitJt5Q4pnDpKI5lCupACbhGuSjwmtXwHho6Fk1/YIEskimdKKbEiS5DQmjXliE
pOkuI4a6gBrD4DhDNb5l6AvNL/+jvgQo7EYP0My+9B7+6SSep+zzOGcTp1oxfdZG
ocKcQNH0C0npu1GUiCEK4J5bxMNIoYEbo9Jh7Aw/BGtYVaEh3owL4lcre2IHr58P
wmG4r3kvfYbFKOpzRqSbofVvAgc4Wk9PpuLZ6AVuflUStpC/bugj8G3olGFjQmGb
f31C29SRETrUnJ7io/pzJQc98Bjj3lp01HwWUd8G7QIDAQABo4IBHzCCARswCQYD
VR0TBAIwADAtBglghkgBhvhCAQ0EIBYeRWFzeS1SU0EgR2VuZXJhdGVkIENlcnRp
ZmljYXRlMB0GA1UdDgQWBBSCu9MCv5gxnCCtTyAhZ/2Kk+GtzDCBnQYDVR0jBIGV
MIGSgBR1ihSSDfNutzZPi08VbD8YFZBk3qF3pHUwczELMAkGA1UEBhMCTkExDTAL
BgNVBAgTBE5vbmUxDTALBgNVBAcTBE5vbmUxEDAOBgNVBAoTB011bGx2YWQxEzAR
BgNVBAMTCk11bGx2YWQgQ0ExHzAdBgkqhkiG9w0BCQEWEGluZm9AbXVsbHZhZC5u
ZXSCAQMwEwYDVR0lBAwwCgYIKwYBBQUHAwIwCwYDVR0PBAQDAgeAMA0GCSqGSIb3
DQEBBQUAA4IBAQBNylzN4J1Ny7/RCZNvcGCxj8EMofiy8mOcrxNc4bAO/YJI8rMd
umor73H6byrQdiL91xpTgjfvMc+MfVVLQ0NhlnA+PAdO6lXnUw82/TZ9QUsyiHQ2
OfGjdQaBwl7zEqlb6hI+c08XfMpa6wczHIEwj/NTaynmdy8/JWGtZqAKUrb2bFM9
0pFeMpxcDfk+RiS2jvK0hR0EzmBRnrKuXP0X2b3VNLNaEIbgn6/u2J26iH7+T8hk
7U27Kkp6vvacm82TKI3PbJf/9oHY70PHjZtzFheN6C5HNt8cur4B32v3/Xm476q+
+5MRo2s8+2c9za/0tvrpA2sFZczg7a7ChKg8
-----END CERTIFICATE-----

This unpacks to human-readable (as you may verify here, or via terminal) as:

Common Name: Mullvad179348453541
Valid From: December 31, 2008
Valid To: November 22, 2024
Issuer: master.mullvad.net, Mullvad
Key Size: 2048 bit
Serial Number: 1212117 (0x127ed5)

The second PEM-encoded cert is the first ASCII-armoured textblock in the file ca.crt:

-----BEGIN CERTIFICATE-----
MIIEQjCCAyqgAwIBAgIBAzANBgkqhkiG9w0BAQUFADBzMQswCQYDVQQGEwJOQTEN
MAsGA1UECBMETm9uZTENMAsGA1UEBxMETm9uZTEQMA4GA1UEChMHTXVsbHZhZDET
MBEGA1UEAxMKTXVsbHZhZCBDQTEfMB0GCSqGSIb3DQEJARYQaW5mb0BtdWxsdmFk
Lm5ldDAeFw0wOTAzMjQxNjE5NDhaFw0xOTAzMjIxNjE5NDhaMHsxCzAJBgNVBAYT
Ak5BMQ0wCwYDVQQIEwROb25lMQ0wCwYDVQQHEwROb25lMRAwDgYDVQQKEwdNdWxs
dmFkMRswGQYDVQQDExJtYXN0ZXIubXVsbHZhZC5uZXQxHzAdBgkqhkiG9w0BCQEW
EGluZm9AbXVsbHZhZC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDFADld/psMt/92pJO/JhvWyErlPM4cLBaAomGm6WNLcKGAbw4Mu6m20b31oHiC
CU2UIqp3fAk2Qs2lppBzJ0IAMeTUi0k2ZaMlgrgm19H1tam+V5OdfNYc35qHgVML
F4HRDcrcTRkT+hHm2mjrgQU54x46P/ziZDyYPImpQrMwcFdWofUIsnUSoDaTnWnp
fhFx2RzofewDIRF6CnoDNbq4sgw6b1eIYkU9DGwY/yFJN65AeG1FUimsIa1KAWFn
CwHErLCIl1L/yzoh8BQrwXmNeTUU/Jw/bMli/IzHqFE0dRwj1du5RAgcDBcsISq0
KdsVWeepHNYZGe/ka+p4bXaNAgMBAAGjgdgwgdUwHQYDVR0OBBYEFHWKFJIN8263
Nk+LTxVsPxgVkGTeMIGlBgNVHSMEgZ0wgZqAFOFjtD5Vo9I3X946kUhRSyAa8pvF
oXekdTBzMQswCQYDVQQGEwJOQTENMAsGA1UECBMETm9uZTENMAsGA1UEBxMETm9u
ZTEQMA4GA1UEChMHTXVsbHZhZDETMBEGA1UEAxMKTXVsbHZhZCBDQTEfMB0GCSqG
SIb3DQEJARYQaW5mb0BtdWxsdmFkLm5ldIIJAIRoLqBRKrvUMAwGA1UdEwQFMAMB
Af8wDQYJKoZIhvcNAQEFBQADggEBAKS0Yj3LflezvSpB4DuU0EwIaYqxcxUTIMnX
sLZdZUpNHSfMyhEOhvplYSY5wlSO2ut4ITcOx6TSF4pLrReEJV4kDpqB/9EbDjKb
9IHgB+mPncFDf0AwAQd8AsfEnAVITL9BaVfB07ujWgEXlrDJACJXL4TaRTNubCsT
xa91p7JrcW4TLJcO2ZPabdk0xgZ9DuK40ngTeQ+srKhoqXJzetirewqwVLXzzikN
R4IMtNkgZP/vF0aS3mXoZ846kt7kPplzn3p8AHIHOXh3N2KJotsk/WAq4IJX9lWU
9nlHGckTO123a2YU1H08dnXpo1W6tJIwO61mcgw5S8yVqbwG7ys=
-----END CERTIFICATE-----

It unpacks as...

Common Name: master.mullvad.net
Organization: Mullvad
Locality: None
State: None
Country: NA
Valid From: March 24, 2009
Valid To: March 22, 2019
Issuer: Mullvad CA, Mullvad
Key Size: 2048 bit
Serial Number: 3 (0x3)

That makes sense, as it's simply the PEM-encoded version of the human-readable certificate that is right above it in ca.crt.

However, the third PEM-encoded cert that is in the installer - which is the second block of PEM-encoded text in the file ca.crt, is this:

-----BEGIN CERTIFICATE-----
MIIEQjCCAyqgAwIBAgIJAIRoLqBRKrvUMA0GCSqGSIb3DQEBBQUAMHMxCzAJBgNV
BAYTAk5BMQ0wCwYDVQQIEwROb25lMQ0wCwYDVQQHEwROb25lMRAwDgYDVQQKEwdN
dWxsdmFkMRMwEQYDVQQDEwpNdWxsdmFkIENBMR8wHQYJKoZIhvcNAQkBFhBpbmZv
QG11bGx2YWQubmV0MB4XDTA5MDMyNDA2NDcyNVoXDTE5MDMyMjA2NDcyNVowczEL
MAkGA1UEBhMCTkExDTALBgNVBAgTBE5vbmUxDTALBgNVBAcTBE5vbmUxEDAOBgNV
BAoTB011bGx2YWQxEzARBgNVBAMTCk11bGx2YWQgQ0ExHzAdBgkqhkiG9w0BCQEW
EGluZm9AbXVsbHZhZC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDNNzZOrq+gMaA6wfyWdNFmxlM2OB1czwFgtPiDd9f6F8m6CGYBQog3Q2Wx3yAv
hxt/uchFBCKtYz6Yh59BCxXKfNAQT2uaMC6KAvKFgz0wppi4S8YbWg2KDelNO/Zv
Rb1QT4CBWMbtYzCQZvlJpHr2ZwuXG2OiT477oMyX5Hmf+iT0drmqi+wylRr7CRBs
LBu+fxLZ2LFD5g6MATuL3ql5JLIoVjlSqIgbld74pD4WUnM61HRwFsKoCEjq409Y
QNP1xO7BeaJu3uQvg/HJhXnGZxTatXhqvdCuAPQRppQ4UnkUzxdSTrfgM3hqMony
vX1vy0dX1S8iTQCIeyzAYNObAgMBAAGjgdgwgdUwHQYDVR0OBBYEFOFjtD5Vo9I3
X946kUhRSyAa8pvFMIGlBgNVHSMEgZ0wgZqAFOFjtD5Vo9I3X946kUhRSyAa8pvF
oXekdTBzMQswCQYDVQQGEwJOQTENMAsGA1UECBMETm9uZTENMAsGA1UEBxMETm9u
ZTEQMA4GA1UEChMHTXVsbHZhZDETMBEGA1UEAxMKTXVsbHZhZCBDQTEfMB0GCSqG
SIb3DQEJARYQaW5mb0BtdWxsdmFkLm5ldIIJAIRoLqBRKrvUMAwGA1UdEwQFMAMB
Af8wDQYJKoZIhvcNAQEFBQADggEBAMjMAFPDeFOrQsvMXD/x+CuARwegS2PDZuB5
f1Svw3YDF6cB1jlc0F12nh9SZxaYRwKIlpYoolLCOLoUCLwQJ0gsokxLV7G4gVb8
dzETnNq4HG/QOPwPisjoOCaEmcd0tx1EkyNY0KLqFZTS0VdmDHCn89dDFA/6yuYI
5u04uJs7c/K4qaW7X6ajOOdneqjbtPeVOvx9DWXHxA0xz4Y+/w4laX/OTRD7jySq
K9fLfRliE5zsxzpUr5EWxAnqiABoWL71SiItk5fG8k3MJJ9SVr+YnTHmE7S4KNqu
4wTksvkb0Tmjae1lRSlMd6u2AulAxVcVKAod2QVffhj+hdkYM94=
-----END CERTIFICATE-----

This 3rd PEM-block unpacks to:

Common Name: Mullvad CA
Organization: Mullvad
Locality: None
State: None
Country: NA
Valid From: March 23, 2009
Valid To: March 21, 2019
Issuer: Mullvad CA, Mullvad
Key Size: 2048 bit
Serial Number: 84682ea0512abbd4

So there's three separate blocks of PEM-encoded certificate materials included in the installer: two in the file ca.crt (as you can confirm simply by looking at the file), and one in the file mullvad.crt. Two of those PEM-encodings have their equivalent human-readable materials also included in the installer, although it's not clear there's any benefit to having such duplicate versions of the same "certificate" propagated (nor is there a security risk in doing so, to be clear).

The third block of PEM-encoded materials does not have a corresponding non-PEM cert included in the installer.

Those are the raw materials, as distributed in the installer.

Judging by the screenshot you simply copied-and-pasted the wrong certificate into the online tool. The client certificate was used instead of the one from the certificate authority file. Of course the client key matches its own certificate.

Now we have only one PEM-encoded "private key," which is in mullvad.key and is the following:

-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQC3aEoJRq5KR6MB
R8wmWXXMHKgfjTnmTw59xZud0O4PzHMJmK0m3lDimcOkojmUK6kAJuEa5KPCa1fA
eGjoWTX9ggSySKZ0opsSJLkNCaNeWISk6S4jhrqAGsPgOEM1vmXoC80v/6O+BCjs
Rg/QzL70Hv7pJJ6n7PM4ZxOnWjF91kahwpxA0fQLSem7UZSIIQrgnlvEw0ihgRuj
0mHsDD8Ea1hVoSHejAviVyt7Ygevnw/CYbiveS99hsUo6nNGpJuh9W8CBzhaT0+m
4tnoBW5+VRK2kL9u6CPwbeiUYWNCYZt/fULb1JEROtScnuKj+nMlBz3wGOPeWnTU
fBZR3wbtAgMBAAECggEBAI2Ht+IyndqKL1qUmhBZ5pIM5xv58l0sUoVx0SVWje65
GWilXbDpy8chWx0XZpFVo8OPPRRwrYIhLYVEJchu1z/6bj9Z2sGUnU/B8N8DugLb
EfjkTAt0M0UZ4l+Layn09FS9jqhkgGnocd/qLNg2t4BQzusArEHvkrzKphr1ec2d
FUVp+yz1unzLM6wZI09gwDtpkpFzRk6bNtMPwrP0m35CFW0t59mDQHHHxit59yEb
+dcupp7a5l4J9CUFlA9jdJuK94ZxG8+1iu4WyqRK/6iKoqSrTQ4Z1Z2QJ/TQzYpU
StDolZJ5dYRY5TStqbly+FwJzb1iJobHqSsxoY0xbs0CgYEA8iIxER5gfVtzu6lG
hWprSKO658lbSPHJNb/YxnkiNhJ8dAdkWvE4wyRwsITk9SpQXXcX3fPkLRAlhmre
fz/Dr/rcjrW4VXbLZrHHcSbdC1fFXI2+LTiwCAQqQhPeMgPDXKOwOuG2/YWxuZgY
MONi8OfQIVKVlDcmAmIKVABo6IsCgYEAwekj3hC/Oow7cAlscIV0hZRGTHKjG936
LCZIvMiU7OmVQXXHrYtLWN/LVpN0gmuywc7sTLszJRjeSl1k+6uvKo7eGd7/D/8+
OTEdAU1d15gKITlcP5+XEYDZmV3EqELtP02TxHrq7mIpbl7c8tgHx5K6BWE68gWZ
k2Qme8Z0RWcCgYEAi595ydRJcZ/tobYf60kNakq3uXbcA7kg/LSO7Qvm1WVdjI7C
qMpWn/iAXtmTKWhoBS1qfttnpTCdYuB3QstjLTQsQMK689VXvvUe+7mcVzEapp85
ndwFbenw8D+CrjaLTf053wpPOewBKvNwZ6iHYkFaPAziIiCW82LTb9L4q7cCgYAs
CqzH0hvsy07wqmNDxzvo3v18fYkIWklo36Ujo5cXnBH3VS3t/7Y0UFgZqNIMkTN/
i2TmJJqAMX7DeyTleGAHlX1ieOCLnJhgWwRQeGb5AaJDW4jVNoUUR6SkjcSNxu2l
tBP8y0IytH7ef5NFYMWbkXrIoAXIVHdGH7gR4sgjvwKBgCH1KjlW2hnfpsxMKahO
FDS4+yqLSv3ZEPNADmVsw18aBe/B9TqOKz7sAktgiMVLJdrghYfVMXAx+qm9WdyL
8eo1PAQauXZpUQU9SGOdUI7bn/ly4snf1sPByuGfTohx4VG9Vtnc7UyTyaBAghEn
tkil/6NrGF0qwd0F+Z16WgcD
-----END PRIVATE KEY-----

This private key is paired with the following certificate:

-----BEGIN CERTIFICATE-----
MIIENzCCAx+gAwIBAgIDEn7VMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAk5B
MQ0wCwYDVQQIEwROb25lMQ0wCwYDVQQHEwROb25lMRAwDgYDVQQKEwdNdWxsdmFk
MRswGQYDVQQDExJtYXN0ZXIubXVsbHZhZC5uZXQxHzAdBgkqhkiG9w0BCQEWEGlu
Zm9AbXVsbHZhZC5uZXQwHhcNMDkwMTAxMDAwMDAwWhcNMjQxMTIzMDUxNTMxWjAe
MRwwGgYDVQQDExNNdWxsdmFkMTc5MzQ4NDUzNTQxMIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEAt2hKCUauSkejAUfMJll1zByoH4055k8OfcWbndDuD8xz
CZitJt5Q4pnDpKI5lCupACbhGuSjwmtXwHho6Fk1/YIEskimdKKbEiS5DQmjXliE
pOkuI4a6gBrD4DhDNb5l6AvNL/+jvgQo7EYP0My+9B7+6SSep+zzOGcTp1oxfdZG
ocKcQNH0C0npu1GUiCEK4J5bxMNIoYEbo9Jh7Aw/BGtYVaEh3owL4lcre2IHr58P
wmG4r3kvfYbFKOpzRqSbofVvAgc4Wk9PpuLZ6AVuflUStpC/bugj8G3olGFjQmGb
f31C29SRETrUnJ7io/pzJQc98Bjj3lp01HwWUd8G7QIDAQABo4IBHzCCARswCQYD
VR0TBAIwADAtBglghkgBhvhCAQ0EIBYeRWFzeS1SU0EgR2VuZXJhdGVkIENlcnRp
ZmljYXRlMB0GA1UdDgQWBBSCu9MCv5gxnCCtTyAhZ/2Kk+GtzDCBnQYDVR0jBIGV
MIGSgBR1ihSSDfNutzZPi08VbD8YFZBk3qF3pHUwczELMAkGA1UEBhMCTkExDTAL
BgNVBAgTBE5vbmUxDTALBgNVBAcTBE5vbmUxEDAOBgNVBAoTB011bGx2YWQxEzAR
BgNVBAMTCk11bGx2YWQgQ0ExHzAdBgkqhkiG9w0BCQEWEGluZm9AbXVsbHZhZC5u
ZXSCAQMwEwYDVR0lBAwwCgYIKwYBBQUHAwIwCwYDVR0PBAQDAgeAMA0GCSqGSIb3
DQEBBQUAA4IBAQBNylzN4J1Ny7/RCZNvcGCxj8EMofiy8mOcrxNc4bAO/YJI8rMd
umor73H6byrQdiL91xpTgjfvMc+MfVVLQ0NhlnA+PAdO6lXnUw82/TZ9QUsyiHQ2
OfGjdQaBwl7zEqlb6hI+c08XfMpa6wczHIEwj/NTaynmdy8/JWGtZqAKUrb2bFM9
0pFeMpxcDfk+RiS2jvK0hR0EzmBRnrKuXP0X2b3VNLNaEIbgn6/u2J26iH7+T8hk
7U27Kkp6vvacm82TKI3PbJf/9oHY70PHjZtzFheN6C5HNt8cur4B32v3/Xm476q+
+5MRo2s8+2c9za/0tvrpA2sFZczg7a7ChKg8
-----END CERTIFICATE-----

...which, itself, is included in the file mullvad.crt. This in turn reverses to:

Common Name: Mullvad179348453541
Valid From: December 31, 2008
Valid To: November 22, 2024
Issuer: master.mullvad.net, Mullvad
Key Size: 2048 bit
Serial Number: 1212117 (0x127ed5)

One of these certificates is, apparently, intended to be cancelled via inclusion in crl.pem. Because the encoding of that PEM-block is nonstandard, it's difficult to confirm which of the three certificates is actually intended to be cancelled as pre-heartbleed.

You state that "the client certificate was used instead of the one from the certificate authority file" - but there's actually two certificates in the ca.crt file (well, three... two are commutative transforms of each other). The private key matches neither of those two certificates, agreed.

Given the mis-mash of cert materials included in this installer, perhaps it's best I simply ask you to explain which cert is supposed to be which: which is cancelled as pre-heartbleed, which is a client-side cert, and which is the public hash of the server-side certs you are using? I've done my best, per the post above, to impute intentionality as to which is supposed to be which... but in the end that is (as I said in the post) a bit of a toss-up because of the surfeit of cert materials - and the improperly PEM'd crl entry - included in the installer.

Even though no actual vulnerability was published, it is still unfortunate that you chose not to practice responsible disclosure. Had your claims been true you would have subjected our users to unnecessary risk by not contacting us. We still haven't received any notice from you.

It is not our experience in regards to disclosure that a full and well-documented publication of a vulnerability is "irresponsible." Indeed, the days of attempts to negotiate corrections of vulns via private appeals to vendors proved to be largely ineffective. Hence the near-universal move to public disclosure of vulns.

An irresponsible approach would have been for us to share these findings only with select parties, or to sell this vuln to a third party. We did neither - we published it, and this enables you to correct it quickly. It also allows us to discuss it publicly, as we're doing here, which is healthy for all.

We are competitors but we are also colleagues fighting against a common threat. When we find potential vulnerabilities (such as OpenVPN's vulnerability to Shellshock or Heartbleed) that affect other VPN services we warn them first if appropriate.

We agree that we have common interests in protecting people from dragnet surveillance, and it is in that spirit that we publish this vuln in the first place. As we've said before - as I've said, personally, before - the only thing we earn when we disclose such things is enemies. It benefits us as a company not at all.

It does benefit the larger community, and this is why we do it.

So, in closing, I'd encourage you to clean up the cert materials in your installer. Remove the chuff, as it has confused the process to the point where materials not intended for disclosure have been disclosed. It also likely resulted in your attempted revocation of pre-hb certificate materials ineffective, unfortunately.

Thank you for taking the time and care to reply, and we hope this has been a constructive dialogue.

Regards,

~ pj

Postby **Pattern_Juggled** » Thu Nov 27, 2014 3:15 am

I believe the heart of the problem here is the inclusion of excess cert materials in ca.crt; I'm just not clear on why there's two PEM-blocks and one human-readable cert in "ca.crt" - and I can't think of a good reason for it. As I said in the original post, without running this through openvpn for test connects, I am not even sure what the client-side daemon is going to do with these duplicate ASCII-armoured PEMs... does it just try the first one and, if that finds a suitable match with materials provided by the server via TLS handshake, assume that's correct? If the first isn't validated server-side, does it then try the second, stepwise?

This shouldn't be such a chore to untangle. Simply put, ca.crt is supposed to be the public side of the server's identify verification. For example, our ca.crt materials (which we inline in conf's, as is preferred in current builds of openvpn), are as follows:

-----BEGIN CERTIFICATE-----
MIIFHjCCBAagAwIBAgIJAKekpGXxXvhbMA0GCSqGSIb3DQEBCwUAMIG6MQswCQYD
VQQGEwJDQTELMAkGA1UECBMCUUMxETAPBgNVBAcTCE1vbnRyZWFsMTYwNAYDVQQK
FC1LYXRhbmEgSG9sZGluZ3MgTGltaXRlIC8gIGNyeXB0b3N0b3JtX2RhcmtuZXQx
ETAPBgNVBAsTCFRlY2ggT3BzMRcwFQYDVQQDFA5jcnlwdG9zdG9ybV9pczEnMCUG
CSqGSIb3DQEJARYYY2VydGFkbWluQGNyeXB0b3N0b3JtLmlzMB4XDTE0MDQyNTE3
MTAxNVoXDTE3MTIyMjE3MTAxNVowgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJR
QzERMA8GA1UEBxMITW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBM
aW1pdGUgLyAgY3J5cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMx
FzAVBgNVBAMUDmNyeXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRt
aW5AY3J5cHRvc3Rvcm0uaXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDJaOSYIX/sm+4/OkCgyAPYB/VPjDo9YBc+zznKGxd1F8fAkeqcuPpGNCxMBLOu
mLsBdxLdR2sppK8cu9kYx6g+fBUQtShoOj84Q6+n6F4DqbjsHlLwUy0ulkeQWk1v
vKKkpBViGVFsZ5ODdZ6caJ2UY2C41OACTQdblCqaebsLQvp/VGKTWdh9UsGQ3LaS
Tcxt0PskqpGiWEUeOGG3mKE0KWyvxt6Ox9is9QbDXJOYdklQaPX9yUuII03Gj3xm
+vi6q2vzD5VymOeTMyky7Geatbd2U459Lwzu/g+8V6EQl8qvWrXESX/ZXZvNG8QA
cOXU4ktNBOoZtws6TzknpQF3AgMBAAGjggEjMIIBHzAdBgNVHQ4EFgQUOFjh918z
L4vR8x1q3vkp6npwUSUwge8GA1UdIwSB5zCB5IAUOFjh918zL4vR8x1q3vkp6npw
USWhgcCkgb0wgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJRQzERMA8GA1UEBxMI
TW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBMaW1pdGUgLyAgY3J5
cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMxFzAVBgNVBAMUDmNy
eXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRtaW5AY3J5cHRvc3Rv
cm0uaXOCCQCnpKRl8V74WzAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IB
AQAK6B7AOEqbaYjXoyhXeWK1NjpcCLCuRcwhMSvf+gVfrcMsJ5ySTHg5iR1/LFay
IEGFsOFEpoNkY4H5UqLnBByzFp55nYwqJUmLqa/nfIc0vfiXL5rFZLao0npLrTr/
inF/hecIghLGVDeVcC24uIdgfMr3Z/EXSpUxvFLGE7ELlsnmpYBxm0rf7s9S9wtH
o6PjBpb9iurF7KxDjoXsIgHmYAEnI4+rrArQqn7ny4vgvXE1xfAkFPWR8Ty1ZlxZ
gEyypTkIWhphdHLSdifoOqo83snmCObHgyHG2zo4njXGExQhxS1ywPvZJRt7fhjn
X03mQP3ssBs2YRNR5hR5cMdC
-----END CERTIFICATE-----

This unpacks to our post-heartbleed, sever-side CA credentials as follows:

Common Name: cryptostorm_is
Organization: Katana Holdings Limite / cryptostorm_darknet
Organization Unit: Tech Ops
Locality: Montreal
State: QC
Country: CA
Valid From: April 25, 2014
Valid To: December 22, 2017
Issuer: cryptostorm_is, Katana Holdings Limite / cryptostorm_darknet
Key Size: 2048 bit
Serial Number: a7a4a465f15ef85b

That a 1:1 mapping between ca.crt and the certificate server-side whose private key us used for TLS validation exists seems utterly fundamental to this process; introducing one-to-many ambiguity in that mapping is the root of what's gone wrong here, as far as I can tell.

Regards,

~ pj

Mullvad · Postby **Mullvad** » Thu Nov 27, 2014 3:41 am

Pattern_Juggled wrote:the third is the PEM-encoded version of the certificate in human-readable form that is included in the file "mullvad.crt."

No it's not. As your own quotes show:

Common Name: Mullvad CA
Organization: Mullvad
Locality: None
State: None
Country: NA
Valid From: March 23, 2009
Valid To: March 21, 2019
Issuer: Mullvad CA, Mullvad
Key Size: 2048 bit
Serial Number: 84682ea0512abbd4

Common Name: Mullvad179348453541
Valid From: December 31, 2008
Valid To: November 22, 2024
Issuer: master.mullvad.net, Mullvad
Key Size: 2048 bit
Serial Number: 1212117 (0x127ed5)

Not the same.

Pattern_Juggled wrote:The private key matches neither of those two certificates, agreed.

Unlike what you claim in your original post. Thus your entire conclusion is false. No private server keys have been leaked.

Postby **Pattern_Juggled** » Thu Nov 27, 2014 3:45 am

...both of the "certificates" included in ca.crt show "valid from" dates of 2009; the first (PEM-encoded) one shows 24 March 2009 as valid-from; the second one shows 23 March 2009.

Despite that, it seems that the first is intended to be a post-hb server certificate... with the second actually being the pre-heartbleed server certificate? Neither is a CSR and both ASCII-identify as proper certificates,..

Perhaps there's a rational structure here that I simply am not grasping; as I said in my original post in this thread, the surfeit of cert materials makes parsing this less clearcut than would be optimal.

Postby **Pattern_Juggled** » Thu Nov 27, 2014 3:48 am

Mullvad wrote:Unlike what you claim in your original post. Thus your entire conclusion is false. No private server keys have been leaked.

I'm not as confident in echoing this conclusion as you are, given that it's not clear which of these certificates is being used by openvpn as representing the server!

My intention is not to be tendentious, and as I've said repeatedly perhaps there's some structural explanation here that I have simply failed to impute. But when faced with ca.crt including the following materials, it's not obvious what happens in production:

Code: Select all

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 3 (0x3)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=NA, ST=None, L=None, O=Mullvad, CN=Mullvad CA/emailAddress=info@mullvad.net
        Validity
            Not Before: Mar 24 16:19:48 2009 GMT
            Not After : Mar 22 16:19:48 2019 GMT
        Subject: C=NA, ST=None, L=None, O=Mullvad, CN=master.mullvad.net/emailAddress=info@mullvad.net
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:c5:00:39:5d:fe:9b:0c:b7:ff:76:a4:93:bf:26:
                    1b:d6:c8:4a:e5:3c:ce:1c:2c:16:80:a2:61:a6:e9:
                    63:4b:70:a1:80:6f:0e:0c:bb:a9:b6:d1:bd:f5:a0:
                    78:82:09:4d:94:22:aa:77:7c:09:36:42:cd:a5:a6:
                    90:73:27:42:00:31:e4:d4:8b:49:36:65:a3:25:82:
                    b8:26:d7:d1:f5:b5:a9:be:57:93:9d:7c:d6:1c:df:
                    9a:87:81:53:0b:17:81:d1:0d:ca:dc:4d:19:13:fa:
                    11:e6:da:68:eb:81:05:39:e3:1e:3a:3f:fc:e2:64:
                    3c:98:3c:89:a9:42:b3:30:70:57:56:a1:f5:08:b2:
                    75:12:a0:36:93:9d:69:e9:7e:11:71:d9:1c:e8:7d:
                    ec:03:21:11:7a:0a:7a:03:35:ba:b8:b2:0c:3a:6f:
                    57:88:62:45:3d:0c:6c:18:ff:21:49:37:ae:40:78:
                    6d:45:52:29:ac:21:ad:4a:01:61:67:0b:01:c4:ac:
                    b0:88:97:52:ff:cb:3a:21:f0:14:2b:c1:79:8d:79:
                    35:14:fc:9c:3f:6c:c9:62:fc:8c:c7:a8:51:34:75:
                    1c:23:d5:db:b9:44:08:1c:0c:17:2c:21:2a:b4:29:
                    db:15:59:e7:a9:1c:d6:19:19:ef:e4:6b:ea:78:6d:
                    76:8d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                75:8A:14:92:0D:F3:6E:B7:36:4F:8B:4F:15:6C:3F:18:15:90:64:DE
            X509v3 Authority Key Identifier: 
                keyid:E1:63:B4:3E:55:A3:D2:37:5F:DE:3A:91:48:51:4B:20:1A:F2:9B:C5
                DirName:/C=NA/ST=None/L=None/O=Mullvad/CN=Mullvad CA/emailAddress=info@mullvad.net
                serial:84:68:2E:A0:51:2A:BB:D4

            X509v3 Basic Constraints: 
                CA:TRUE
    Signature Algorithm: sha1WithRSAEncryption
        a4:b4:62:3d:cb:7e:57:b3:bd:2a:41:e0:3b:94:d0:4c:08:69:
        8a:b1:73:15:13:20:c9:d7:b0:b6:5d:65:4a:4d:1d:27:cc:ca:
        11:0e:86:fa:65:61:26:39:c2:54:8e:da:eb:78:21:37:0e:c7:
        a4:d2:17:8a:4b:ad:17:84:25:5e:24:0e:9a:81:ff:d1:1b:0e:
        32:9b:f4:81:e0:07:e9:8f:9d:c1:43:7f:40:30:01:07:7c:02:
        c7:c4:9c:05:48:4c:bf:41:69:57:c1:d3:bb:a3:5a:01:17:96:
        b0:c9:00:22:57:2f:84:da:45:33:6e:6c:2b:13:c5:af:75:a7:
        b2:6b:71:6e:13:2c:97:0e:d9:93:da:6d:d9:34:c6:06:7d:0e:
        e2:b8:d2:78:13:79:0f:ac:ac:a8:68:a9:72:73:7a:d8:ab:7b:
        0a:b0:54:b5:f3:ce:29:0d:47:82:0c:b4:d9:20:64:ff:ef:17:
        46:92:de:65:e8:67:ce:3a:92:de:e4:3e:99:73:9f:7a:7c:00:
        72:07:39:78:77:37:62:89:a2:db:24:fd:60:2a:e0:82:57:f6:
        55:94:f6:79:47:19:c9:13:3b:5d:b7:6b:66:14:d4:7d:3c:76:
        75:e9:a3:55:ba:b4:92:30:3b:ad:66:72:0c:39:4b:cc:95:a9:
        bc:06:ef:2b
-----BEGIN CERTIFICATE-----
MIIEQjCCAyqgAwIBAgIBAzANBgkqhkiG9w0BAQUFADBzMQswCQYDVQQGEwJOQTEN
MAsGA1UECBMETm9uZTENMAsGA1UEBxMETm9uZTEQMA4GA1UEChMHTXVsbHZhZDET
MBEGA1UEAxMKTXVsbHZhZCBDQTEfMB0GCSqGSIb3DQEJARYQaW5mb0BtdWxsdmFk
Lm5ldDAeFw0wOTAzMjQxNjE5NDhaFw0xOTAzMjIxNjE5NDhaMHsxCzAJBgNVBAYT
Ak5BMQ0wCwYDVQQIEwROb25lMQ0wCwYDVQQHEwROb25lMRAwDgYDVQQKEwdNdWxs
dmFkMRswGQYDVQQDExJtYXN0ZXIubXVsbHZhZC5uZXQxHzAdBgkqhkiG9w0BCQEW
EGluZm9AbXVsbHZhZC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDFADld/psMt/92pJO/JhvWyErlPM4cLBaAomGm6WNLcKGAbw4Mu6m20b31oHiC
CU2UIqp3fAk2Qs2lppBzJ0IAMeTUi0k2ZaMlgrgm19H1tam+V5OdfNYc35qHgVML
F4HRDcrcTRkT+hHm2mjrgQU54x46P/ziZDyYPImpQrMwcFdWofUIsnUSoDaTnWnp
fhFx2RzofewDIRF6CnoDNbq4sgw6b1eIYkU9DGwY/yFJN65AeG1FUimsIa1KAWFn
CwHErLCIl1L/yzoh8BQrwXmNeTUU/Jw/bMli/IzHqFE0dRwj1du5RAgcDBcsISq0
KdsVWeepHNYZGe/ka+p4bXaNAgMBAAGjgdgwgdUwHQYDVR0OBBYEFHWKFJIN8263
Nk+LTxVsPxgVkGTeMIGlBgNVHSMEgZ0wgZqAFOFjtD5Vo9I3X946kUhRSyAa8pvF
oXekdTBzMQswCQYDVQQGEwJOQTENMAsGA1UECBMETm9uZTENMAsGA1UEBxMETm9u
ZTEQMA4GA1UEChMHTXVsbHZhZDETMBEGA1UEAxMKTXVsbHZhZCBDQTEfMB0GCSqG
SIb3DQEJARYQaW5mb0BtdWxsdmFkLm5ldIIJAIRoLqBRKrvUMAwGA1UdEwQFMAMB
Af8wDQYJKoZIhvcNAQEFBQADggEBAKS0Yj3LflezvSpB4DuU0EwIaYqxcxUTIMnX
sLZdZUpNHSfMyhEOhvplYSY5wlSO2ut4ITcOx6TSF4pLrReEJV4kDpqB/9EbDjKb
9IHgB+mPncFDf0AwAQd8AsfEnAVITL9BaVfB07ujWgEXlrDJACJXL4TaRTNubCsT
xa91p7JrcW4TLJcO2ZPabdk0xgZ9DuK40ngTeQ+srKhoqXJzetirewqwVLXzzikN
R4IMtNkgZP/vF0aS3mXoZ846kt7kPplzn3p8AHIHOXh3N2KJotsk/WAq4IJX9lWU
9nlHGckTO123a2YU1H08dnXpo1W6tJIwO61mcgw5S8yVqbwG7ys=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEQjCCAyqgAwIBAgIJAIRoLqBRKrvUMA0GCSqGSIb3DQEBBQUAMHMxCzAJBgNV
BAYTAk5BMQ0wCwYDVQQIEwROb25lMQ0wCwYDVQQHEwROb25lMRAwDgYDVQQKEwdN
dWxsdmFkMRMwEQYDVQQDEwpNdWxsdmFkIENBMR8wHQYJKoZIhvcNAQkBFhBpbmZv
QG11bGx2YWQubmV0MB4XDTA5MDMyNDA2NDcyNVoXDTE5MDMyMjA2NDcyNVowczEL
MAkGA1UEBhMCTkExDTALBgNVBAgTBE5vbmUxDTALBgNVBAcTBE5vbmUxEDAOBgNV
BAoTB011bGx2YWQxEzARBgNVBAMTCk11bGx2YWQgQ0ExHzAdBgkqhkiG9w0BCQEW
EGluZm9AbXVsbHZhZC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDNNzZOrq+gMaA6wfyWdNFmxlM2OB1czwFgtPiDd9f6F8m6CGYBQog3Q2Wx3yAv
hxt/uchFBCKtYz6Yh59BCxXKfNAQT2uaMC6KAvKFgz0wppi4S8YbWg2KDelNO/Zv
Rb1QT4CBWMbtYzCQZvlJpHr2ZwuXG2OiT477oMyX5Hmf+iT0drmqi+wylRr7CRBs
LBu+fxLZ2LFD5g6MATuL3ql5JLIoVjlSqIgbld74pD4WUnM61HRwFsKoCEjq409Y
QNP1xO7BeaJu3uQvg/HJhXnGZxTatXhqvdCuAPQRppQ4UnkUzxdSTrfgM3hqMony
vX1vy0dX1S8iTQCIeyzAYNObAgMBAAGjgdgwgdUwHQYDVR0OBBYEFOFjtD5Vo9I3
X946kUhRSyAa8pvFMIGlBgNVHSMEgZ0wgZqAFOFjtD5Vo9I3X946kUhRSyAa8pvF
oXekdTBzMQswCQYDVQQGEwJOQTENMAsGA1UECBMETm9uZTENMAsGA1UEBxMETm9u
ZTEQMA4GA1UEChMHTXVsbHZhZDETMBEGA1UEAxMKTXVsbHZhZCBDQTEfMB0GCSqG
SIb3DQEJARYQaW5mb0BtdWxsdmFkLm5ldIIJAIRoLqBRKrvUMAwGA1UdEwQFMAMB
Af8wDQYJKoZIhvcNAQEFBQADggEBAMjMAFPDeFOrQsvMXD/x+CuARwegS2PDZuB5
f1Svw3YDF6cB1jlc0F12nh9SZxaYRwKIlpYoolLCOLoUCLwQJ0gsokxLV7G4gVb8
dzETnNq4HG/QOPwPisjoOCaEmcd0tx1EkyNY0KLqFZTS0VdmDHCn89dDFA/6yuYI
5u04uJs7c/K4qaW7X6ajOOdneqjbtPeVOvx9DWXHxA0xz4Y+/w4laX/OTRD7jySq
K9fLfRliE5zsxzpUr5EWxAnqiABoWL71SiItk5fG8k3MJJ9SVr+YnTHmE7S4KNqu
4wTksvkb0Tmjae1lRSlMd6u2AulAxVcVKAod2QVffhj+hdkYM94=
-----END CERTIFICATE-----

Postby **Pattern_Juggled** » Thu Nov 27, 2014 3:54 am

I'd like to propose that this question be settled by doing some test connects to the network, and dumping verb-9 connection logs as well as pcaps of the session. This will tell us what the sessions are actually doing, what keys are actually being used, and what cipher suites are instantiated.

I do not believe this is going to come clear at a level appropriate for final resolution by only looking at the conflicting cert materials in the installer.

Mullvad · Postby **Mullvad** » Thu Nov 27, 2014 4:11 am

Then please set up a proof-of-concept server using the (non-existing) leaked private server keys. According to yourself, it's less than a 15-minute job.

Postby **Pattern_Juggled** » Thu Nov 27, 2014 4:20 am

Yes, that's what I've pointed out - a broken server validation process doesn't actually need "PoC" anything; one simply sets up a server-side instance, points the client-side files at it, and confirms that a connection is possible. This is, as I said, less than a 15 minute job... as I am sure you will agree :-)

This process is functionally commutative with an analysis of as-observed TLS mechanics during connections to default server instances. In fact, one could well argue that looking at actual sessions to actual servers is more instructive - or instructive in a different way - than is a PoC that causes sessions to initiate with a spoofed server-side instance.

Or, indeed, one can simply do both... and see what falls out of the tree, as it were. I vote for that one, as it's most informative for all. Agreed?

Cheers,

~ pj

Mullvad · Postby **Mullvad** » Thu Nov 27, 2014 4:40 am

Start with creating a server instance (using a - non-existing - leaked private key, as you please) that mullvadconfig.zip above will connect to. We'll check back in 15 minutes.

Postby **Pattern_Juggled** » Thu Nov 27, 2014 4:52 am

This is "ca.crt" with origination date of 6 November 2013 (as pulled from the attached archive:

mullvad-41.tar.gz: (6.55 MiB) Downloaded 343 times

-----BEGIN CERTIFICATE-----
MIIEQjCCAyqgAwIBAgIJAIRoLqBRKrvUMA0GCSqGSIb3DQEBBQUAMHMxCzAJBgNV
BAYTAk5BMQ0wCwYDVQQIEwROb25lMQ0wCwYDVQQHEwROb25lMRAwDgYDVQQKEwdN
dWxsdmFkMRMwEQYDVQQDEwpNdWxsdmFkIENBMR8wHQYJKoZIhvcNAQkBFhBpbmZv
QG11bGx2YWQubmV0MB4XDTA5MDMyNDA2NDcyNVoXDTE5MDMyMjA2NDcyNVowczEL
MAkGA1UEBhMCTkExDTALBgNVBAgTBE5vbmUxDTALBgNVBAcTBE5vbmUxEDAOBgNV
BAoTB011bGx2YWQxEzARBgNVBAMTCk11bGx2YWQgQ0ExHzAdBgkqhkiG9w0BCQEW
EGluZm9AbXVsbHZhZC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDNNzZOrq+gMaA6wfyWdNFmxlM2OB1czwFgtPiDd9f6F8m6CGYBQog3Q2Wx3yAv
hxt/uchFBCKtYz6Yh59BCxXKfNAQT2uaMC6KAvKFgz0wppi4S8YbWg2KDelNO/Zv
Rb1QT4CBWMbtYzCQZvlJpHr2ZwuXG2OiT477oMyX5Hmf+iT0drmqi+wylRr7CRBs
LBu+fxLZ2LFD5g6MATuL3ql5JLIoVjlSqIgbld74pD4WUnM61HRwFsKoCEjq409Y
QNP1xO7BeaJu3uQvg/HJhXnGZxTatXhqvdCuAPQRppQ4UnkUzxdSTrfgM3hqMony
vX1vy0dX1S8iTQCIeyzAYNObAgMBAAGjgdgwgdUwHQYDVR0OBBYEFOFjtD5Vo9I3
X946kUhRSyAa8pvFMIGlBgNVHSMEgZ0wgZqAFOFjtD5Vo9I3X946kUhRSyAa8pvF
oXekdTBzMQswCQYDVQQGEwJOQTENMAsGA1UECBMETm9uZTENMAsGA1UEBxMETm9u
ZTEQMA4GA1UEChMHTXVsbHZhZDETMBEGA1UEAxMKTXVsbHZhZCBDQTEfMB0GCSqG
SIb3DQEJARYQaW5mb0BtdWxsdmFkLm5ldIIJAIRoLqBRKrvUMAwGA1UdEwQFMAMB
Af8wDQYJKoZIhvcNAQEFBQADggEBAMjMAFPDeFOrQsvMXD/x+CuARwegS2PDZuB5
f1Svw3YDF6cB1jlc0F12nh9SZxaYRwKIlpYoolLCOLoUCLwQJ0gsokxLV7G4gVb8
dzETnNq4HG/QOPwPisjoOCaEmcd0tx1EkyNY0KLqFZTS0VdmDHCn89dDFA/6yuYI
5u04uJs7c/K4qaW7X6ajOOdneqjbtPeVOvx9DWXHxA0xz4Y+/w4laX/OTRD7jySq
K9fLfRliE5zsxzpUr5EWxAnqiABoWL71SiItk5fG8k3MJJ9SVr+YnTHmE7S4KNqu
4wTksvkb0Tmjae1lRSlMd6u2AulAxVcVKAod2QVffhj+hdkYM94=
-----END CERTIFICATE-----

...which unpacks as...

Common Name: Mullvad CA
Organization: Mullvad
Locality: None
State: None
Country: NA
Valid From: March 23, 2009
Valid To: March 21, 2019
Issuer: Mullvad CA, Mullvad
Key Size: 2048 bit
Serial Number: 84682ea0512abbd4

Which is, in fact, one of the PEM-blocks included in the currently-distributed version of ca.crt. It's the second block, actually. This is, most likely, pre-heartbleed certificate material... but if that's the case, and as you've said in twitter it's not the certificate that is intended to be revoked in the CRL file (leaving the question of which cert is being revoked, or intended to be revoked?), then why is a pre-heartbleed cert being circulated in cr.crt?

Again, I do not know what openvpn will do when presented with multiple cert blocks client-side and asked to validate server identity with them. I do not recall ever reading this use-case in the official documentation, and I've never set up a system in this way to test firsthand. So this reflects ignorance on my part - rather than guess, test.

It is a well-known characteristic of X-509-based frameworks that they can be brittle in production. Indeed, smart people have noted how common these issues are in the wild... and that's with CA-issued certs, not self-generated! Throwing known-erroneous materials at the x509 cert process is a recipe for unexpected, and security-unfriendly, outcomes.

You make the point that my original assertion that the "private key" published in your installer is a confirmed match for the server certificate is not the only way to read the materials in the installer. That point is valid, and I am in agreement with that point. I did, in my original post, acknowledge that the excess volume of cert material in the installer bundle makes interpretation a challenge... perhaps I should have been more forceful in making that point, and acknowledging the ambiguity it inevitably brings forth. In that respect, I apologise for a lack of forcefulness in balancing that ambiguity against my conclusion that the private key is a match for the server-side materials actually being used by network sessions given the connection parameters included in the installer.

However, I've also asked for an explanation of how the multiple-cert reality of the installer framework you are distributing is intended to be parsed by openvpn... and so far I don't think that's been provided. Without that, we are left to guess as to intent - or to test and see what actually happens.

What does seem clear is that pre-heartbleed cert material is being distributed in your installers. Further, the conflicting/contradictory cert materials in ca.crt, as well as the overlapping naming conventions used in both the ca.crt certificates and the (intended) "client" cert in mullvad.crt call into question exactly how this jumble is going to get parsed in actual network sessions. This, too, seems an unambiguous conclusion given the data available.

I suspect that testing, and log analysis, will show much more than further argument about what the installer files are intended to do, or "should" do, or are correctly being read as doing. But, as always, I could certainly be wrong.

Cheers,

~ pj

Postby **Pattern_Juggled** » Thu Nov 27, 2014 5:26 am

Yes ok, it's become a big geeky... but really fascinating, also!

It is this kind of heated discussion that helps shake out the thin spots in our understanding of PKI and related concepts. I speak personally, here, in terms of benefitting from a debate/discussion such as this with a knowledgeable person who is willing to make strong arguments. And for this, I am genuinely thankful... I also suspect some folks reading along are benefitting as this dialogue unfolds, even during the rough spots.

Postby **Graze** » Thu Nov 27, 2014 5:30 am

Actually good to see stuff getting flushed out - helps everyone be better, as both PJ and Mullvad mentioned up above. Good works, all!

*runs to store for more popcorn*

Postby **cryptostorm_support** » Thu Nov 27, 2014 5:40 am

Mullvad · Postby **Mullvad** » Thu Nov 27, 2014 7:06 am

Pattern_Juggled wrote:You make the point that my original assertion that the "private key" published in your installer is a confirmed match for the server certificate is not the only way to read the materials in the installer. That point is valid, and I am in agreement with that point.

We make the point that both your assertion and conclusion were dead wrong and that you spent your day gloating about it here and all over Twitter without even notifying us. Instead you could have taken a few minutes to double check your results, think about their implications or even, you know, test that it actually worked. Any one of those three actions would have prevented this spectacle.

All other threads of the discussion - how to read CRLs, PKI design, why some certificates generated pre-Heartbleed don't need to be revoked - just diverts attention away from your original claims.

Pattern_Juggled wrote:I did, in my original post, acknowledge that the excess volume of cert material in the installer bundle makes interpretation a challenge... perhaps I should have been more forceful in making that point, and acknowledging the ambiguity it inevitably brings forth. In that respect, I apologise for a lack of forcefulness in balancing that ambiguity against my conclusion that the private key is a match for the server-side materials actually being used by network sessions given the connection parameters included in the installer.

This is woefully inadequate. The honourable thing is to make the apology at least as strongly and as publicly as the error.

Postby **Pattern_Juggled** » Thu Nov 27, 2014 7:23 am

Mullvad wrote:We make the point that both your assertion and conclusion were dead wrong and that you spent your day gloating about it here and all over Twitter without even notifying us. Instead you could have taken a few minutes to double check your results, think about their implications or even, you know, test that it actually worked. Any one of those three actions would have prevented this spectacle.

We are not in agreement in this regard, and I have invested considerable time in this thread documenting why that is the case.

All other threads of the discussion - how to read CRLs, PKI design, why some certificates generated pre-Heartbleed don't need to be revoked - just diverts attention away from your original claims.

That you fail to see the connection amoungst these inter-related problems with your setup is, in a word, disappointing. That you have refused to provide even a modicum of competent explanation when asked basic questions about these issues is, in a word, instructive.

This is woefully inadequate. The honourable thing is to make the apology at least as strongly and as publicly as the error.

Whilst more than willing to apologises for errors, I am equally unwilling to apologise simply because someone is made uncomfortable due to a lack of available cogent explanation for obvious flaws in security systems.

Finally, that you feel it appropriate to veer towards needlessly sharp words rather than responding to direct questions regarding cryptographic fundamentals is unfortunate.

Cheers,

~ pj

Bottle 'o Rummm · Postby **Bottle 'o Rummm** » Fri Jan 23, 2015 6:02 am

Pattern_Juggled wrote:
-MASSIVE SNIP-

Yikes, I was actually going to use Mullvad before discovering cryptostorm. Thankfully I didn't. :clap:

mullvad.net

mullvad.net

Re: mullvad.net

Re: mullvad.net

Re: mullvad.net

Re: mullvad.net

Re: mullvad.net

Re: mullvad.net

Re: mullvad.net

Re: mullvad.net

Re: mullvad.net

Re: mullvad.net

Re: mullvad.net

ca.crt versioning

Re: mullvad.net

Re: mullvad.net

Re: mullvad.net

Re: mullvad.net

Re: mullvad.net

Re: mullvad.net

Who is online

Login