I rischi associati alla distribuzione della chiave privata crittografata con il nostro software?

1

Il nostro software contiene due eseguibili che devono servire i dati su SSL (e molti che devono fare richieste su HTTPS).
Ho notato che è distribuito con alcuni file .PEM creati con OpenSSL. Questi file vengono letti dal software quando ha bisogno di consumare o servire su HTTPS.
Il secondo file dice: INIZIA CHIAVE PRIVATA CRIPTATA

Domanda: Se le chiavi private non dovrebbero mai essere distribuite, è corretto distribuire la versione crittografata?
Corriamo rischi con questo?

Ho letto È una cattiva pratica aggiungere una chiave privata crittografata al controllo del codice sorgente? , ma non sono ancora chiaro sulla possibilità che altri facciano qualcosa di malevolo (spoofing?) Con quella chiave privata crittografata.

(BTW In realtà c'è un terzo certificato intermedio a causa del problema di RapidSSL i certificati non sono affidabili su Android , ma ciò sembra irrilevante alla domanda).

Primo file

intestazione:

Bag Attributes
    localKeyID: 01 00 00 00 
    friendlyName: TimeTellbv wildcard
subject=/serialNumber=34VD79pOnKBR2dM5LC69jkD7PGuRM6VC/OU=GT04962750/OU=See www.rapidssl.com/resources/cps (c)13/OU=Domain Control Validated - RapidSSL(R)/CN=*.timetellbv.nl
issuer=/C=US/O=GeoTrust, Inc./CN=RapidSSL CA
-----BEGIN CERTIFICATE-----

Convertito in testo con

c:\OpenSSL-Win32\bin\openssl x509 -in tt_https.pem -inform PEM -noout -text >tt_https.txt

legge:

Certificate:
Data:
    Version: 3 (0x2)
    Serial Number: 962889 (0xeb149)
Signature Algorithm: sha1WithRSAEncryption
    Issuer: C=US, O=GeoTrust, Inc., CN=RapidSSL CA
    Validity
        Not Before: Oct 23 04:44:55 2013 GMT
        Not After : Oct 25 11:45:46 2016 GMT
    Subject: serialNumber=34VD79pOnKBR2dM5LC69jkD7PGuRM6VC, OU=GT04962750, OU=See www.rapidssl.com/resources/cps (c)13, OU=Domain Control Validated - RapidSSL(R), CN=*.timetellbv.nl
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (2048 bit)
            Modulus:
                00:d4:a4:bf:b9:bb:cf:f9:e9:88:95:f3:e5:c7:b9:
                [snip]
                e7:27
            Exponent: 65537 (0x10001)
    X509v3 extensions:
        X509v3 Authority Key Identifier: 
            keyid:6B:69:3D:6A:18:42:4A:DD:8F:02:65:39:FD:35:24:86:78:91:16:30

        X509v3 Key Usage: critical
            Digital Signature, Key Encipherment
        X509v3 Extended Key Usage: 
            TLS Web Server Authentication, TLS Web Client Authentication
        X509v3 Subject Alternative Name: 
            DNS:*.timetellbv.nl, DNS:timetellbv.nl
        X509v3 CRL Distribution Points: 

            Full Name:
              URI:http://rapidssl-crl.geotrust.com/crls/rapidssl.crl

        X509v3 Subject Key Identifier: 
            CA:86:AC:B6:13:D3:96:F8:60:5F:DF:B2:F6:FA:28:E0:75:30:DB:D0
        X509v3 Basic Constraints: critical
            CA:FALSE
        Authority Information Access: 
            OCSP - URI:http://rapidssl-ocsp.geotrust.com
            CA Issuers - URI:http://rapidssl-aia.geotrust.com/rapidssl.crt

        X509v3 Certificate Policies: 
            Policy: 2.16.840.1.113733.1.7.54
              CPS: http://www.geotrust.com/resources/cps

Signature Algorithm: sha1WithRSAEncryption
     56:b9:59:c1:ed:d1:a5:84:2a:ce:96:14:0e:ad:db:fc:80:80:
     [snip]
     c7:7c:10:fb

Secondo file

intestazione:

Bag Attributes
    Microsoft Local Key set: <No Values>
    localKeyID: 01 00 00 00 
    friendlyName: le-0f8807ed-4cbe-43a6-84a9-94ef82e3fd39
    Microsoft CSP Name: Microsoft RSA SChannel Cryptographic Provider
Key Attributes
    X509v3 Key Usage: 10 
-----BEGIN ENCRYPTED PRIVATE KEY-----

La conversione al modulo di testo non riesce:

c:\OpenSSL-Win32\bin\openssl x509 -in tt_https_key.pem -inform PEM -noout -text >tt_https_key.txt

unable to load certificate
2180:error:0906D06C:PEM routines:PEM_read_bio:no start line:.\crypto\pem\pem_lib
.c:696:Expecting: TRUSTED CERTIFICATE
    
posta Jan Doggen 04.03.2014 - 09:00
fonte

1 risposta

0

Ci sono casi in cui puoi effettivamente distribuire la chiave privata (anche non crittografata) ma sono veramente borderline (ad esempio, potresti voler ridurre la quantità di connessioni SSL che il tuo server accetterà prima di eseguire l'autenticazione del client ma potrebbe non avere la possibilità di emettere correttamente ogni cliente il proprio auth auth cert).

Non sembra che sia quello che stai facendo qui, però: quel certificato è un certificato certificato server jolly per il dominio timetellbv.nl. Non ha molto senso usarlo per l'autenticazione del client (sarebbe meglio usare la propria CA per questo), quindi probabilmente lo stai usando per servire il file.

Quindi, la prossima domanda sarebbe: che tipo di distribuzione stiamo parlando? Se si sta parlando di una distribuzione a sito singolo (ovvero si tratta del proprio certificato e si sta distribuendo la propria app sul proprio server), potrebbe essere una cattiva pratica collocare i certificati nel pacchetto di distribuzione (vedere la domanda hai collegato), ma non sta invalidando l'intera sicurezza.

Se, tuttavia, stai distribuendo un'applicazione da o verso una terza parte, allora questo è un grande no-no: l'unico modo per usare tale certificato è di usarlo in modo errato: non è corretto identificarlo sistema ma quelli sotto il dominio * .timetellbv.nl e non dovrebbero essere usati.

(Come nota a margine, link restituisce un certificato non valido: il nome DNS non corrisponde)

    
risposta data 04.03.2014 - 09:48
fonte

Leggi altre domande sui tag