Analysieren Sie die Prinzipien von HTTPS und seine Verwendung in Android

Wenn HTTP1.x Daten überträgt, liegen alle übertragenen Inhalte im Klartext vor. Weder der Client noch der Server können die Identität der anderen Partei überprüfen. Die bestehenden Probleme sind wie folgt:

• Die Kommunikation erfolgt im Klartext (nicht verschlüsselt) und der Inhalt kann abgehört werden;
• Wenn Sie die Identität der kommunizierenden Partei nicht überprüfen, kann es zu einer Tarnung kommen;
• Die Integrität der Nachricht kann nicht nachgewiesen werden, daher wurde sie möglicherweise manipuliert;

Tatsächlich treten diese Probleme nicht nur bei HTTP auf, sondern auch bei anderen unverschlüsselten Protokollen.

(1) Kommunikation im Klartext kann abgehört werden

Gemäß dem Funktionsmechanismus der TCP/IP-Protokollsuite besteht die Gefahr, dass Kommunikationsinhalte überall im Internet abgehört werden. Das HTTP-Protokoll selbst verfügt nicht über die Verschlüsselungsfunktion und alle übertragenen Daten sind Klartext. Selbst wenn die Kommunikation verschlüsselt wurde, wird der Kommunikationsinhalt eingesehen, was mit der unverschlüsselten Kommunikation identisch ist. Dies bedeutet lediglich, dass es bei verschlüsselter Kommunikation möglicherweise unmöglich ist, die Bedeutung der Nachrichteninformationen zu entschlüsseln, die verschlüsselte Nachricht selbst jedoch weiterhin sichtbar ist.

(2) Das Versäumnis, die Identität der kommunizierenden Partei zu überprüfen, kann zu einer Verschleierung führen

Da während der HTTP-Protokollkommunikation keine Verarbeitungsschritte zur Bestätigung der kommunizierenden Partei erforderlich sind, kann jeder eine Anfrage initiieren. Darüber hinaus gibt der Server, solange er die Anfrage empfängt, eine Antwort zurück, unabhängig davon, wer die andere Partei ist. Wenn die Kommunikationspartei nicht bestätigt wird, lauern daher folgende versteckte Gefahren:

• Es ist unmöglich festzustellen, ob der Webserver, an den die Anfrage gesendet wird, derjenige ist, der die Antwort gemäß der wahren Absicht zurückgibt. Möglicherweise handelt es sich um einen getarnten Webserver;
• Es gibt keine Möglichkeit festzustellen, ob der Client, an den die Antwort zurückgegeben wird, derjenige ist, der die Antwort wie beabsichtigt erhalten hat. Möglicherweise handelt es sich um einen getarnten Kunden;
• Es ist nicht möglich festzustellen, ob die andere Partei, mit der Sie kommunizieren, Zugriffsrechte hat. Da einige Webserver wichtige Informationen speichern, möchten sie nur bestimmten Benutzern Kommunikationsberechtigungen erteilen;
• Es ist unmöglich festzustellen, woher die Anfrage kam und wer sie gestellt hat;
• Selbst bedeutungslose Anfragen werden wie befohlen angenommen und können DoS-Angriffe bei massiven Anfragen nicht verhindern;

(3) Die Integrität der Nachricht kann nicht nachgewiesen werden und sie wurde möglicherweise manipuliert

Die sogenannte Vollständigkeit bezieht sich auf die Richtigkeit von Informationen. Wenn die Vollständigkeit nicht nachgewiesen werden kann, kann in der Regel nicht beurteilt werden, ob die Informationen korrekt sind. Das HTTP-Protokoll kann die Integrität der Kommunikationsnachrichten nicht nachweisen. In der Zeit nach dem Senden der Anfrage oder Antwort bis zum Empfang durch die andere Partei gibt es keine Möglichkeit festzustellen, ob der Inhalt der Anfrage oder Antwort manipuliert wurde.

Beim Herunterladen von Inhalten von einer Website ist es beispielsweise unmöglich festzustellen, ob die vom Client heruntergeladenen Dateien und die auf dem Server gespeicherten Dateien konsistent sind. Möglicherweise wurde der Dateiinhalt während der Übertragung mit anderen Inhalten manipuliert. Selbst wenn sich der Inhalt tatsächlich geändert hat, ist sich dies für den Kunden als Empfänger nicht bewusst. So wird ein Angriff, bei dem die Anfrage oder Antwort vom Angreifer abgefangen und der Inhalt während der Übertragung manipuliert wird, Man-in-the-Middle-Angriff (MITM) genannt.

(4) Mehrere Eigenschaften, die eine sichere HTTP-Version haben sollte

Aufgrund der oben genannten Probleme ist eine HTTP-Sicherheitstechnologie erforderlich, die die folgenden Funktionen bereitstellen kann:

(1) Serverauthentifizierung (Clients wissen, dass sie mit einem echten Server und nicht mit einem gefälschten Server sprechen);

(2) Client-Authentifizierung (Server wissen, dass sie mit einem echten Client und nicht mit einem gefälschten Client sprechen);

(3) Integrität (Daten auf Client und Server werden nicht verändert);

(4) Verschlüsselung (die Konversation zwischen Client und Server ist privat, es besteht kein Grund zur Sorge, abgehört zu werden);

(5) Effizienz (ein Algorithmus, der schnell genug läuft, um von Low-End-Clients und -Servern verwendet zu werden);

(6) Universalität (grundsätzlich unterstützen alle Clients und Server diese Protokolle);

Im Kontext dieser Nachfrage wurde die HTTPS-Technologie geboren. Die Hauptfunktionen des HTTPS-Protokolls basieren im Wesentlichen auf dem TLS/SSL-Protokoll, das Authentifizierungs-, Informationsverschlüsselungs- und Integritätsüberprüfungsfunktionen bereitstellt, die die Sicherheitsprobleme von HTTP lösen können. Dieser Abschnitt konzentriert sich auf mehrere wichtige technische Punkte des HTTPS-Protokolls.

(1) Verschlüsselungstechnologie

Verschlüsselungsalgorithmen werden im Allgemeinen in zwei Typen unterteilt:

Symmetrische Verschlüsselung: Der Schlüssel für die Ver- und Entschlüsselung ist derselbe. Dargestellt durch den DES-Algorithmus;

Asymmetrische Verschlüsselung: Die Schlüssel zur Ver- und Entschlüsselung sind unterschiedlich. Dargestellt durch den RSA-Algorithmus;

Symmetrische Verschlüsselung ist sehr stark und kann im Allgemeinen nicht geknackt werden. Ein großes Problem besteht jedoch darin, dass der Schlüssel nicht sicher generiert und gespeichert werden kann. Wenn jede Sitzung zwischen dem Client und dem Server einen festen, gleichen Schlüssel für die Verschlüsselung und Entschlüsselung verwendet, muss dies der Fall sein große Sicherheitsrisiken darstellen.

Vor dem Aufkommen asymmetrischer Schlüsselaustauschalgorithmen bestand ein großes Problem bei der symmetrischen Verschlüsselung darin, nicht zu wissen, wie Schlüssel sicher generiert und gespeichert werden. Der asymmetrische Schlüsselaustauschprozess dient hauptsächlich dazu, dieses Problem zu lösen und die Generierung und Verwendung von Schlüsseln sicherer zu machen. Aber es ist auch der „Übeltäter“, der die HTTPS-Leistung und -Geschwindigkeit erheblich beeinträchtigt.

HTTPS verwendet einen hybriden Verschlüsselungsmechanismus, der sowohl symmetrische als auch asymmetrische Verschlüsselung im Schlüsselaustauschprozess und symmetrische Verschlüsselung in den nachfolgenden Kommunikations- und Nachrichtenaustauschphasen verwendet.

(2) Authentifizierung – Zertifikat zum Nachweis der Richtigkeit des öffentlichen Schlüssels

Eines der größten Probleme bei der asymmetrischen Verschlüsselung besteht darin, dass sie nicht beweisen kann, dass der öffentliche Schlüssel selbst der echte öffentliche Schlüssel ist. Wenn Sie beispielsweise die Kommunikation mit einem bestimmten Server mithilfe der Verschlüsselung mit öffentlichem Schlüssel vorbereiten, müssen Sie nachweisen, dass der empfangene öffentliche Schlüssel der vom ursprünglich erwarteten Server ausgegebene öffentliche Schlüssel ist. Möglicherweise wurde während der Übertragung des öffentlichen Schlüssels der echte öffentliche Schlüssel durch den Angreifer ersetzt.

Wenn die Zuverlässigkeit des öffentlichen Schlüssels nicht überprüft wird, treten mindestens die folgenden zwei Probleme auf: Man-in-the-Middle-Angriff und Informationsverweigerung.

Um die oben genannten Probleme zu lösen, können Sie öffentliche Schlüsselzertifikate verwenden, die von Zertifizierungsstellen für digitale Zertifikate (CA, Certificate Authority) und den damit verbundenen Agenturen ausgestellt wurden.

Der spezifische Prozess für die Verwendung von CA ist wie folgt:

(1) Der Serverbetreiber beantragt einen öffentlichen Schlüssel bei der Zertifizierungsstelle (CA) für digitale Zertifikate;

(2) CA überprüft die Authentizität der vom Antragsteller online, offline und auf andere Weise bereitgestellten Informationen, z. B. ob die Organisation existiert, ob das Unternehmen legal ist, ob es Eigentümer des Domainnamens ist usw.;

(3) Wenn die Informationen genehmigt werden, signiert die Zertifizierungsstelle den angewendeten öffentlichen Schlüssel digital, verteilt dann den signierten öffentlichen Schlüssel, fügt den öffentlichen Schlüssel in das Zertifikat des öffentlichen Schlüssels ein und bindet es zusammen. Das Zertifikat enthält die folgenden Informationen: den öffentlichen Schlüssel des Antragstellers, die organisatorischen Informationen und persönlichen Informationen des Antragstellers, die Informationen der ausstellenden Behörde CA, die Gültigkeitsdauer, die Seriennummer des Zertifikats und weitere Informationen im Klartext sowie eine Signatur Signaturgenerierungsalgorithmus: Verwenden Sie zunächst den Hash. Die Spaltenfunktion berechnet den Informationsauszug der öffentlichen Klartextinformationen und verwendet dann den privaten Schlüssel der Zertifizierungsstelle, um den Informationsauszug zu verschlüsseln, und der Chiffretext ist die Signatur;

(4) Der Client sendet während der HTTPS-Handshake-Phase eine Anfrage an den Server und fordert den Server auf, die Zertifikatsdatei zurückzugeben;

(5) Der Client liest die relevanten Klartextinformationen im Zertifikat, berechnet mit derselben Hash-Funktion den Informationsauszug, entschlüsselt dann mit dem öffentlichen Schlüssel der entsprechenden Zertifizierungsstelle die Signaturdaten und vergleicht den Informationsauszug des Zertifikats. Wenn es konsistent ist, kann es die Legitimität des Zertifikats bestätigen, das heißt, der öffentliche Schlüssel ist legitim;

(6) Der Kunde überprüft dann die Informationen zum Domänennamen, die Gültigkeitsdauer und andere Informationen im Zusammenhang mit dem Zertifikat;

(7) Der Client verfügt über integrierte vertrauenswürdige CA-Zertifikatinformationen (einschließlich öffentlichem Schlüssel). Wenn die CA nicht vertrauenswürdig ist, wird das der CA entsprechende Zertifikat nicht gefunden und das Zertifikat wird als illegal beurteilt.

Achten Sie bei diesem Vorgang auf einige Punkte:

(1) Bei der Beantragung eines Zertifikats muss kein privater Schlüssel angegeben werden, wodurch sichergestellt wird, dass der private Schlüssel für immer nur vom Server verwaltet werden kann;

(2) Die Gültigkeit des Zertifikats hängt weiterhin vom asymmetrischen Verschlüsselungsalgorithmus ab. Das Zertifikat fügt hauptsächlich Serverinformationen und Signaturen hinzu;

(3) Das der integrierten Zertifizierungsstelle entsprechende Zertifikat wird als Stammzertifikat bezeichnet. Der Aussteller und der Benutzer sind identisch und sie signieren für sich selbst, was als selbstsigniertes Zertifikat bezeichnet wird

enum { 
    rsa_sign(1), dss_sign(2), rsa_fixed_dh(3),dss_fixed_dh(4), 
    rsa_ephemeral_dh_RESERVED(5),dss_ephemeral_dh_RESERVED(6), 
    fortezza_dms_RESERVED(20), 
    ecdsa_sign(64), rsa_fixed_ecdh(65), 
    ecdsa_fixed_ecdh(66),  
    (255) 
} ClientCertificateType; 

opaque DistinguishedName<1..2^16-1>;struct { 
    ClientCertificateType certificate_types<1..2^8-1>; 
    SignatureAndHashAlgorithm 
      supported_signature_algorithms<2^16-1>; 
    DistinguishedName certificate_authorities<0..2^16-1>; 
} CertificateRequest;

struct {  
Signature handshake_messages_signature;  
} CertificateVerify;

struct {  
    AlertLevel level;  
    AlertDescription description;  
} Alert;

HostnameVerifier DO_NOT_VERIFY = new HostnameVerifier() { 
  @Override 
  public boolean verify(String hostname, SSLSession session) { 
    // 设置接受的域名集合 
    if (hostname.equals(...))  { 
         return true; 
    } 
  } 
}; 

HttpsURLConnection.setDefaultHostnameVerifier(DO_NOT_VERIFY);

03-09 09:21:38.427: W/System.err(2496): javax.net.ssl.SSLHandshakeException: javax.net.ssl.SSLProtocolException: SSL handshake aborted: ssl=0xb7fa0620: Failure in SSL library, usually a protocol error 

03-09 09:21:38.427: W/System.err(2496): error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure (external/openssl/ssl/s23_clnt.c:741 0xa90e6990:0x00000000)

SSLSocketFactory noSSLv3Factory; 
if (Build.VERSION.SDK_INT <= Build.VERSION_CODES.KITKAT) { 
    noSSLv3Factory = new TLSSocketFactory(mSSLContext.getSSLSocket().getSocketFactory()); 
} else { 
    noSSLv3Factory = mSSLContext.getSSLSocket().getSocketFactory(); 
}

public class TLSSocketFactory extends SSLSocketFactory { 

    private SSLSocketFactory internalSSLSocketFactory; 

    public TLSSocketFactory() throws KeyManagementException, NoSuchAlgorithmException { 
        SSLContext context = SSLContext.getInstance("TLS"); 
        context.init(null, null, null); 
        internalSSLSocketFactory = context.getSocketFactory(); 
    } 

    public TLSSocketFactory(SSLSocketFactory delegate) throws KeyManagementException, NoSuchAlgorithmException { 
        internalSSLSocketFactory = delegate; 
    } 

    ...... 

    @Override 
    public Socket createSocket(InetAddress address, int port, InetAddress localAddress, int localPort) throws IOException { 
        return enableTLSOnSocket(internalSSLSocketFactory.createSocket(address, port, localAddress, localPort)); 
    } 

    // 开启对TLS1.1和TLS1.2的支持 
    private Socket enableTLSOnSocket(Socket socket) { 
        if(socket != null && (socket instanceof SSLSocket)) { 
            ((SSLSocket)socket).setEnabledProtocols(new String[] {"TLSv1.1", "TLSv1.2"}); 
        } 
        return socket; 
    } 
}

if (JarConfig.__self_signed_https) { 
    SSLContextByTrustAll mSSLContextByTrustAll = new SSLContextByTrustAll(); 
    MySSLContext mSSLContext = new MySSLContext(mSSLContextByTrustAll); 
   SSLSocketFactory noSSLv3Factory; 
   if (Build.VERSION.SDK_INT <= Build.VERSION_CODES.KITKAT) { 
        noSSLv3Factory = new TLSSocketFactory(mSSLContext.getSSLSocket().getSocketFactory()); 
    } else { 
        noSSLv3Factory = mSSLContext.getSSLSocket().getSocketFactory(); 
    } 

    httpsURLConnection.setSSLSocketFactory(noSSLv3Factory); 
    httpsURLConnection.setHostnameVerifier(MY_DOMAIN_VERIFY); 
}else { 
    httpsURLConnection.setSSLSocketFactory((SSLSocketFactory) SSLSocketFactory.getDefault()); 
    httpsURLConnection.setHostnameVerifier(DO_NOT_VERIFY); 
}

public class SSLContextWithServer implements GetSSLSocket { 

    // 在这里进行服务器正式的名称的配置 
    private String[] serverCertificateNames = {"serverCertificateNames1" ,"serverCertificateNames2"}; 

    @Override 
    public SSLContext getSSLSocket() { 
        String[] caCertString = new String[serverCertificateNames.length]; 
        for(int i = 0 ; i < serverCertificateNames.length ; i++) { 
            try { 
                caCertString[i] = readCaCert(serverCertificateNames[i]); 
            } catch(Exception e) { 

            } 
        } 
        SSLContext mSSLContext = null; 
        try { 
            mSSLContext = SSLContextFactory.getInstance().makeContextWithServer(caCertString); 
        } catch(Exception e) { 

        } 
        return mSSLContext; 
    }

@Override 
    public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException { 
        try { 
            originalX509TrustManager.checkServerTrusted(chain, authType); 
        } catch(CertificateException originalException) { 
            try { 
                X509Certificate[] reorderedChain = reorderCertificateChain(chain); 
                CertPathValidator validator = CertPathValidator.getInstance("PKIX"); 
                CertificateFactory factory = CertificateFactory.getInstance("X509"); 
                CertPath certPath = factory.generateCertPath(Arrays.asList(reorderedChain)); 
                PKIXParameters params = new PKIXParameters(trustStore); 
                params.setRevocationEnabled(false); 
                validator.validate(certPath, params); 
            } catch(Exception ex) { 
                throw originalException; 
            } 
        } 
    }

public class AcceptAllTrustManager implements X509TrustManager { 

    @Override 
    public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException { 
        //do nothing，接受任意客户端证书 
    } 

    @Override 
    public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException { 
        //do nothing，接受任意服务端证书 
    } 

    @Override 
    public X509Certificate[] getAcceptedIssuers() { 
        return null; 
    }

public SSLContext makeContextToTrustAll() throws Exception { 
        AcceptAllTrustManager tm = new AcceptAllTrustManager(); 
        SSLContext sslContext = SSLContext.getInstance("TLS"); 
        sslContext.init(null, new TrustManager[] { tm }, null); 

        return sslContext; 
}

Das obige ist der detaillierte Inhalt vonAnalysieren Sie die Prinzipien von HTTPS und seine Verwendung in Android. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!