Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
∞ take a peek at our legendary cryptostorm_is twitter feed if you're into that kind of thing ∞
Ξ we're rolling out voodoo network security across cryptostorm - big things happening, indeed! Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit GitHub Ξ

cryptostorm: certificates, keys, asymmetric crypto, PKI

Looking for a bit more than customer support, and want to learn more about what cryptostorm is , what we've been announcing lately, and how the cryptostorm network makes the magic? This is a great place to start, so make yourself at home!
User avatar

Topic Author
cryptostorm_team
ForumHelper
Posts: 159
Joined: Sat Mar 02, 2013 12:12 am

cryptostorm: certificates, keys, asymmetric crypto, PKI

Postby cryptostorm_team » Thu Oct 17, 2013 11:19 pm

{direct link: http://pki.cryptostorm.org}

In constructing the cryptostorm darknet, we've made intentional decisions about which parts of the baseline OpenVPN protocol are useful for this specific use-case scenario against the threat models known to be most relevant to our network members. In some respects, our decisions are radically different from the usual approach to configuring a "VPN service" - this is not a bug, it's a feature.

This thread is for discussions of our decision regarding cryptographic certificates, keys, certificate authorities (CAs), and associated infrastructure elements.

    ~ cryptostorm_team
cryptostorm_team - a shared, team-wide forum account (not a person)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: support@cryptostorm.is
live chat support: #cryptostorm

User avatar

Topic Author
cryptostorm_team
ForumHelper
Posts: 159
Joined: Sat Mar 02, 2013 12:12 am

ca.crt

Postby cryptostorm_team » Fri Oct 18, 2013 9:44 am

The way we do things, it's important for clients (i.e. network members) to ensure that they're connecting to our actual mesh of exitnode servers. If that's not assured, there's a risk of "man in the middle" (MiTM) attacks where someone pretends to be cryptostorm and tricks a client into connecting to their fake "secure" network. This is a bad thing, and we work hard to protect against this thread vector.

A big piece of this is done via the tools known as "public key infrastructure" (PKI). There's some mathematical cleverness underlying the whole model, but leaving that aside it's pretty simple to follow:

    We make available a fingerprint (called "ca.crt") that is generated from a private, secret key we never disclose to anyone. The fingerprint can only match up to our private key - it's really hard to fake that match-up (in mathematical terms, it's intended to be "computationally intractable"). With that fingerprint, which we can and do publish publicly and share with anyone who wants it, anyone can confirm that a server claiming to be cryptostorm is, in fact, cryptostorm. Someone pretending isn't going to be able to do the 'secret handshake' with that fingerprint, and validate their identity.

The attached file is our current "ca.crt" - the fingerprint we publish, for anyone to confirm that network sessions intended for our secure exitnodes are in fact connecting to our exitnodes, and not to someone pretending to be us. This fingerprint is required for all network sessions with cryptostorm. Without it, we don't allow someone to connect.

Why do we care? Because if someone connects without going through the cryptographic process of confirming that fingerprint matches our and only our secret key, they are at real risk of being MItM'd. That's a security risk for our members, and therefore we enforce against it by preventing network connections without that fingerprint-confirm step. This has nothing to do with verifying the identity of network members themselves - not at all. It's a validation of the network identity.

If you're doing raw/direct access to our network (using, of course your network access token to show you're entitled to network usage), you'll need to save this "ca.crt" file into your local openvpn directory (which varies based on your operating system). It's the only file you need. We're going to be "inlining" this in the client-side configuration files, in the future. For now, we're keeping it separate to help clarify what it is, why it matters, and how it fits into the whole security model.

Again, this isn't a secret file - it's intended to be public! It's not a "private key" and it doesn't "decrypt" anything. Indeed, it's not used at all for any encryption of data. Rather, it helps confirm that our servers are actually our servers. That's all - it's very important, but it's also a very limited function it serves.

Down the road, we're going to be experimenting with forward-looking PKI architectures such as Moxie Marlinspike's "Convergence" system. They're really compelling, and add some real additional security. Right now, we're actively NOT using the traditional "certificate authority" based system seen in the HTTPS framework commonly. That system is badly, badly broken - horrifically so! Instead, we "self-sign" our ca.crt file. That's not a bug, and it's not because we're lazy. Rather, it's because (until we integrate with Convergence, per above) this is the most reliably secure way to do this part of our security model. Having Comodo or some other lame-assed CA "validate" who we are is a terrible plan - and we're not doing it.

Also, the reason this file looks like "gibberish" is because it is! This is a result of the mathematical relationship between this "public key" and the "private key" which is kept secret on our servers. If this file looked nonrandom - if it had a bunch of 111111s in a row, or whatever - that would be a really bad sign that something was wrong.

ca2.crt
(1.79 KiB) Downloaded 1144 times

[EDIT: changed download and code immediately below to reflect post-hearbleed certs
-cryptostorm_support
]

Code: Select all

-----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-----
cryptostorm_team - a shared, team-wide forum account (not a person)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: support@cryptostorm.is
live chat support: #cryptostorm

User avatar

Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

client keys and certs

Postby Pattern_Juggled » Fri Oct 18, 2013 9:53 am

In our security model, we do not make use of client-side certificates or keys in any way whatsoever!

We're attaching these "vestigial" files to the thread, here, mostly as an academic exercise. They are never needed for connections, and they do not need to be downloaded.

There's a story behind these files - one of which is supposed to be super-top-secret in any network security model that relies on them - and it's a story we're going to tell. But not yet. We expect some readers of this thread will have an "Eureka!" moment and see where we're going with this... but we'll not tip our hand for the time being.

The worst way to break a security model is to ignore its fundamental assumptions and deploy the pieces flat-out wrong. So, for example, having these "private" client-side keys be not-so-private or (can you imagine??) actually re-using the same "secret" client key for every fucking client!! would be tragic. Like - really tragic.

This is a bit of a hot-button issue for me, personally. As will come clean in due course.

Using client-side keys is supposed to protect against some kinds of MiTM attacks. In fact, given the topological structure of multi-client private/secure network services (i.e. "darknets"), this is a discongruent element of a viable security framework. Some additional data on this fact is available in the thread discussing the theory of token-based auth elsewhere on this forum. Basically, there's no reason for the secure network to be picky about confirming unique identity of network members; it doesn't increase member security at all. It's vestigial, best-case, or more often it's deployed in a tragically flawed manner that actually makes network members far less secure against MiTM attacks.

Anyway, here's the files... for those curious about such things.

clientgeneric.crt
(5.43 KiB) Downloaded 279 times

Code: Select all

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2 (0x2)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=CA, ST=QC, L=Montreal, O=Katana Holdings Limite /  cryptostorm_darknet, OU=Tech Ops, CN=cryptostorm_is/emailAddress=certadmin@cryptostorm.is
        Validity
            Not Before: Oct 11 13:43:50 2013 GMT
            Not After : Jun  9 13:43:50 2017 GMT
        Subject: C=CA, ST=QC, L=Montreal, O=Katana Holdings Limite /  cryptostorm_darknet, OU=Tech Ops, CN=clientgeneric/emailAddress=certadmin@cryptostorm.is
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:9e:04:27:a3:eb:37:47:2a:45:01:2d:66:83:63:
                    cf:5e:7d:21:e8:6c:9a:d7:54:ba:f7:0a:c3:e3:c7:
                    ac:03:3b:05:dd:31:4f:f0:38:64:cc:09:18:86:35:
                    8f:7f:ed:76:7c:47:1d:b4:c0:30:9f:eb:e0:60:f2:
                    64:9e:c9:67:b9:da:b9:d8:13:25:e9:d6:bb:8f:2d:
                    a7:9c:97:5f:6e:97:91:51:c3:51:61:50:85:f3:5c:
                    c7:c4:e3:87:67:80:ea:19:12:37:52:39:6f:da:1e:
                    81:36:5a:2f:39:60:f6:8e:3c:87:cd:e5:ec:fe:08:
                    68:d1:19:67:c3:12:60:e7:6c:9d:7e:cc:de:85:a4:
                    70:94:c8:73:08:f2:d6:ca:70:0e:18:66:a2:3c:9e:
                    37:27:0e:97:f6:69:fd:d7:ea:af:5f:0d:bb:cd:9d:
                    a7:4c:8c:7d:9e:85:86:d9:f9:3e:bb:87:5d:4a:e2:
                    fb:13:ee:51:3a:3f:54:90:f1:3e:e5:55:63:79:33:
                    d3:30:9c:45:78:ef:10:ae:97:9c:6c:65:08:d8:55:
                    a6:8a:c0:8a:73:91:98:70:b8:7b:eb:cf:84:79:66:
                    1c:b9:7b:eb:13:d2:b7:5c:fa:08:19:70:63:bd:9e:
                    45:6f:66:4e:de:0c:95:37:cd:49:cf:72:e3:e7:5b:
                    56:01
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Comment:
                Easy-RSA Generated Certificate
            X509v3 Subject Key Identifier:
                CC:7E:57:C1:29:C4:97:DA:09:5B:B8:04:AD:69:32:34:19:AB:2F:C9
            X509v3 Authority Key Identifier:
                keyid:5A:60:94:79:9C:E6:41:AF:B3:70:E0:3E:29:67:CD:17:57:B6:67:D7
                DirName:/C=CA/ST=QC/L=Montreal/O=Katana Holdings Limite /  cryptostorm_darknet/OU=Tech Ops/CN=cryptostorm_is/emailAddress=certadmin@cryptostorm.is
                serial:F5:C8:06:09:0A:56:4B:B2

            X509v3 Extended Key Usage:
                TLS Web Client Authentication
            X509v3 Key Usage:
                Digital Signature
    Signature Algorithm: sha256WithRSAEncryption
         0b:42:06:a2:29:cc:a6:e3:fc:3b:20:24:20:29:04:41:63:7d:
         d1:32:b5:00:90:70:e6:26:18:50:e2:f2:b3:d7:06:a5:dd:11:
         d6:38:06:a2:cf:45:08:2d:b8:a9:b9:6b:0b:05:d7:c9:eb:f1:
         21:99:29:46:e7:a6:04:70:66:f0:67:ca:03:e6:3c:1f:87:f8:
         88:74:4d:6b:2e:9f:f8:9f:07:83:fe:cd:62:53:c3:09:a6:dd:
         5c:a7:bc:85:40:32:2c:e7:3f:e6:71:fd:ba:40:26:53:78:24:
         a4:50:08:ac:ff:14:19:d7:e0:c8:8f:56:26:7d:65:dd:10:95:
         ff:dc:a3:97:c8:3a:7b:39:b7:91:47:f6:4f:47:55:f5:d7:0f:
         52:02:35:8a:64:04:97:b4:aa:c3:ee:6c:53:b5:88:92:04:f3:
         24:ea:e4:84:8f:50:bb:b9:1e:23:34:3c:88:7d:8d:fd:44:8e:
         2e:a7:a1:fe:e6:fb:da:b5:09:d3:71:a9:73:52:06:3a:04:72:
         d5:e9:ae:dc:0b:b1:6c:45:75:d9:b3:2c:13:12:7b:e5:a1:99:
         38:eb:5d:92:de:b6:f9:3b:26:ed:82:98:c9:a0:c9:3e:98:5b:
         ce:8d:b6:ac:d5:2b:c8:78:3f:bd:41:79:12:99:6c:3f:7d:c9:
         29:f8:51:1b
-----BEGIN CERTIFICATE-----
MIIFYzCCBEugAwIBAgIBAjANBgkqhkiG9w0BAQsFADCBujELMAkGA1UEBhMCQ0Ex
CzAJBgNVBAgTAlFDMREwDwYDVQQHEwhNb250cmVhbDE2MDQGA1UEChQtS2F0YW5h
IEhvbGRpbmdzIExpbWl0ZSAvICBjcnlwdG9zdG9ybV9kYXJrbmV0MREwDwYDVQQL
EwhUZWNoIE9wczEXMBUGA1UEAxQOY3J5cHRvc3Rvcm1faXMxJzAlBgkqhkiG9w0B
CQEWGGNlcnRhZG1pbkBjcnlwdG9zdG9ybS5pczAeFw0xMzEwMTExMzQzNTBaFw0x
NzA2MDkxMzQzNTBaMIG5MQswCQYDVQQGEwJDQTELMAkGA1UECBMCUUMxETAPBgNV
BAcTCE1vbnRyZWFsMTYwNAYDVQQKFC1LYXRhbmEgSG9sZGluZ3MgTGltaXRlIC8g
IGNyeXB0b3N0b3JtX2RhcmtuZXQxETAPBgNVBAsTCFRlY2ggT3BzMRYwFAYDVQQD
Ew1jbGllbnRnZW5lcmljMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRtaW5AY3J5cHRv
c3Rvcm0uaXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCeBCej6zdH
KkUBLWaDY89efSHobJrXVLr3CsPjx6wDOwXdMU/wOGTMCRiGNY9/7XZ8Rx20wDCf
6+Bg8mSeyWe52rnYEyXp1ruPLaecl19ul5FRw1FhUIXzXMfE44dngOoZEjdSOW/a
HoE2Wi85YPaOPIfN5ez+CGjRGWfDEmDnbJ1+zN6FpHCUyHMI8tbKcA4YZqI8njcn
Dpf2af3X6q9fDbvNnadMjH2ehYbZ+T67h11K4vsT7lE6P1SQ8T7lVWN5M9MwnEV4
7xCul5xsZQjYVaaKwIpzkZhwuHvrz4R5Zhy5e+sT0rdc+ggZcGO9nkVvZk7eDJU3
zUnPcuPnW1YBAgMBAAGjggFxMIIBbTAJBgNVHRMEAjAAMC0GCWCGSAGG+EIBDQQg
Fh5FYXN5LVJTQSBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFMx+V8Ep
xJfaCVu4BK1pMjQZqy/JMIHvBgNVHSMEgecwgeSAFFpglHmc5kGvs3DgPilnzRdX
tmfXoYHApIG9MIG6MQswCQYDVQQGEwJDQTELMAkGA1UECBMCUUMxETAPBgNVBAcT
CE1vbnRyZWFsMTYwNAYDVQQKFC1LYXRhbmEgSG9sZGluZ3MgTGltaXRlIC8gIGNy
eXB0b3N0b3JtX2RhcmtuZXQxETAPBgNVBAsTCFRlY2ggT3BzMRcwFQYDVQQDFA5j
cnlwdG9zdG9ybV9pczEnMCUGCSqGSIb3DQEJARYYY2VydGFkbWluQGNyeXB0b3N0
b3JtLmlzggkA9cgGCQpWS7IwEwYDVR0lBAwwCgYIKwYBBQUHAwIwCwYDVR0PBAQD
AgeAMA0GCSqGSIb3DQEBCwUAA4IBAQALQgaiKcym4/w7ICQgKQRBY33RMrUAkHDm
JhhQ4vKz1wal3RHWOAaiz0UILbipuWsLBdfJ6/EhmSlG56YEcGbwZ8oD5jwfh/iI
dE1rLp/4nweD/s1iU8MJpt1cp7yFQDIs5z/mcf26QCZTeCSkUAis/xQZ1+DIj1Ym
fWXdEJX/3KOXyDp7ObeRR/ZPR1X11w9SAjWKZASXtKrD7mxTtYiSBPMk6uSEj1C7
uR4jNDyIfY39RI4up6H+5vvatQnTcalzUgY6BHLV6a7cC7FsRXXZsywTEnvloZk4
612S3rb5OybtgpjJoMk+mFvOjbas1SvIeD+9QXkSmWw/fckp+FEb
-----END CERTIFICATE-----


clientgeneric.key
(1.66 KiB) Downloaded 280 times

Code: Select all

-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQCeBCej6zdHKkUB
LWaDY89efSHobJrXVLr3CsPjx6wDOwXdMU/wOGTMCRiGNY9/7XZ8Rx20wDCf6+Bg
8mSeyWe52rnYEyXp1ruPLaecl19ul5FRw1FhUIXzXMfE44dngOoZEjdSOW/aHoE2
Wi85YPaOPIfN5ez+CGjRGWfDEmDnbJ1+zN6FpHCUyHMI8tbKcA4YZqI8njcnDpf2
af3X6q9fDbvNnadMjH2ehYbZ+T67h11K4vsT7lE6P1SQ8T7lVWN5M9MwnEV47xCu
l5xsZQjYVaaKwIpzkZhwuHvrz4R5Zhy5e+sT0rdc+ggZcGO9nkVvZk7eDJU3zUnP
cuPnW1YBAgMBAAECggEALe03OEVdQ6nddIIlkXqpAuWLvWoTdxKBZNwUI1gdfrLg
+XEjssYxRbw/DIL0ulHiZiylTauudkywYn0REbWoGDSiX1Lxag2nZe33EWRNsG8N
JZ6HQKmOxTTqOyeGa2bko3TP724SPGsxUwLTRvIPtzeQoR96yjrXfC7OIbxtvdU2
x5ZWDOkDIz0Kgx5r6jsSMSfmVX3X0OP1VYa3AVyU3PwsBplAwgwhxronPC+JmMhv
UjVtgzjoXOP7NLo7TzTee7cYUcR8BwMMFFRXeTYlYrJBcl5/gJIh8QDwyThCDQa6
2oJsTZRh8HADJqd8g2WrU4kphVq0WU6507pD1EvGIQKBgQDSlTZDVmnytXcoIxkL
XOdPBC0+Ll1Ti0A5ckQ+jl82hxheK0zW9QkcbLkj+GgvOMBKo1tm1SwFgiOCwP0j
u85b4jOUM06kST9qRMPEUmhSUquKOiMa5hi032XvjnCS7RkFWiurHXPk0LYnhVB4
DzEqlrHkPUswKtq5geLEVQrMGwKBgQDAGJzENnHc3GmDqkX4eBWkkqMWdn1ZriQV
tOf4l+CK4rJC0ypUwm2AjSLAHxVWXF3PvibsnbftBonPHWacs698xsV8sXBHrzb5
NeQHOiq/3Wdk08mZtk6ZxK1gd+nrkETQZNVfdw9fi+qW1tuaroEezvfDIpSJcfkU
hFeTLC2QEwKBgQCh+70d1x7wX74k1bqyDuiu01up9Sg812Szy73LEOEUpJ6N8WjO
APbdMpTHopEhodnoj/gDBf8yzYRbU/BkyFZYP4vFeCIKJX3uVK7yGSG+EXF6hnXy
fwSKPT3AJCVcH52bjF0C50j6vcEgbWAUujrrs7drBesMRiqxf8Pbmj8P+QKBgBhm
x/sww1P/97NO/OZsMqueKPNgh9nNgi3ztgfhGxfpZiWQ926e6BQNWZ24FRjMUOpj
yEQEYOnOC9FwdalwNdmO0mVdkNq6SixsCRRV8jo/ILQxJwnMm71yu2dmtCNFR0iF
loky8ZP8jQcuMeU7R5GnTtfN27p97NsLWKiMUxlbAoGAYA0iMVQPnbECyjVoWYzt
MhMTTD7DgaP5q9G3uLfuLQkr7nFI7mBuJJ3eZV5L5CltclFNPTtknEq8ftPQF7IK
QMSdPqtMEZ13ltWuH+h7rbDBMoncgz6rCRy5rCbFsS0Yb4gw7bO5u1ncF4XCD/Wk
elU4Ab/S8aiHmaHzSobNflk=
-----END PRIVATE KEY-----
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f


DDWRTnewb

Re: cryptostorm: certificates, keys, asymmetric crypto, PKI

Postby DDWRTnewb » Sun Jul 31, 2016 7:22 pm

these keys ARE in fact necessary to connect with dd-wrt

the generic client goes under public client cert

and the client key goes under client private key


Guest

Re: cryptostorm: certificates, keys, asymmetric crypto, PKI

Postby Guest » Sat Aug 06, 2016 6:23 pm

Huh?

I've had dd-wrt connected to CS 24/7 for years and never put those certs in. Only CA.crt is required- it depends on your particular dd-wrt version whether it will accept certs inline, or if you need to link an external file- but in any case, ONLY CA.crt is required. The servers don't give a fuck who you are, so long as you have a valid user name/token, and meet the crypto standards necessary to initiate the session.

I suspect you've made multiple changes to your config at once, and are inadvertently attributing connection success to the needless inclusion of extra certs.


Return to “cryptostorm in-depth: announcements, how it works, what it is”

Who is online

Users browsing this forum: No registered users and 7 guests

Login