HTTPS-Konzept und Wireshark-Analyse

Schlüssel- und Verschlüsselungsalgorithmus

Schlüssel : Normalerweise eine Zeichenfolge oder Zahl, die bei der Durchführung von Verschlüsselungs-/Entschlüsselungsalgorithmen verwendet wird. Sowohl der öffentliche Schlüssel als auch der private Schlüssel sind Schlüssel, aber im Allgemeinen ist der öffentliche Schlüssel für die Außenwelt offen und wird zur Verschlüsselung verwendet; der private Schlüssel ist nicht öffentlich und wird zur Entschlüsselung verwendet.

Prinzip des asymmetrischen Verschlüsselungsalgorithmus :

Der öffentliche Schlüssel wird zum Verschlüsseln des Klartextes und der private Schlüssel zum Entschlüsseln des Chiffretextes verwendet. Der Absender (Verschlüsseler) kennt den öffentlichen Schlüssel des Empfängers, und nur der Empfänger (Entschlüsseler) ist der Einzige, der seinen eigenen kennt private Schlüsselpersonen. Das Grundprinzip des asymmetrischen Verschlüsselungsalgorithmus besteht darin, dass der Absender zunächst den öffentlichen Schlüssel des Empfängers kennen und dann den öffentlichen Schlüssel des Empfängers zum Verschlüsseln des Originals verwenden muss, wenn der Absender verschlüsselte Informationen senden möchte, die nur der Empfänger interpretieren kann Text ; Nach Erhalt des verschlüsselten Chiffretexts kann der Empfänger den Chiffretext mit seinem eigenen privaten Schlüssel entschlüsseln . Offensichtlich muss der Empfänger beim asymmetrischen Verschlüsselungsalgorithmus vor der Kommunikation der beiden Parteien dem Sender den öffentlichen Schlüssel geben, den er zufällig generiert hat, und den privaten Schlüssel selbst behalten. Da der asymmetrische Algorithmus über zwei Schlüssel verfügt, eignet er sich besonders für die Datenverschlüsselung in verteilten Systemen. Zu den weit verbreiteten asymmetrischen Verschlüsselungsalgorithmen gehören der RSA-Algorithmus und der vom US National Bureau of Standards vorgeschlagene DSA.

Symmetrischer Verschlüsselungsalgorithmus

Der symmetrische Verschlüsselungsalgorithmus zeichnet sich durch einen offenen Algorithmus, einen geringen Rechenaufwand, eine schnelle Verschlüsselungsgeschwindigkeit und eine hohe Verschlüsselungseffizienz aus.

Der Nachteil besteht darin, dass beide Transaktionsparteien denselben Schlüssel verwenden, sodass die Sicherheit nicht gewährleistet werden kann. Darüber hinaus müssen zwei Benutzer jedes Mal, wenn sie einen symmetrischen Verschlüsselungsalgorithmus verwenden, einen eindeutigen Schlüssel verwenden, der anderen unbekannt ist, wodurch sich die Anzahl der Schlüssel, die sowohl Sender als auch Empfänger besitzen, exponentiell erhöht und die Schlüsselverwaltung für Benutzer zu einer Belastung wird . Symmetrische Verschlüsselungsalgorithmen sind in verteilten Netzwerksystemen schwierig zu verwenden, hauptsächlich weil die Schlüsselverwaltung schwierig ist und die Nutzungskosten hoch sind. Im Vergleich zum Verschlüsselungsalgorithmus mit öffentlichem Schlüssel kann der symmetrische Verschlüsselungsalgorithmus Verschlüsselung und Authentifizierung bereitstellen, verfügt jedoch nicht über die Signaturfunktion, was den Anwendungsbereich einschränkt. Zu den in privaten Computernetzwerksystemen weit verbreiteten symmetrischen Verschlüsselungsalgorithmen gehören DES und IDEA. AES, das vom amerikanischen National Bureau of Standards befürwortet wird, ist dabei, DES als neuen Standard zu ersetzen.

Der Vorteil des symmetrischen Verschlüsselungsalgorithmus liegt in der hohen Geschwindigkeit der Ver- und Entschlüsselung und der Schwierigkeit des Knackens bei Verwendung eines langen Schlüssels. Unter der Annahme, dass zwei Benutzer eine symmetrische Verschlüsselungsmethode verwenden müssen, um Daten zu verschlüsseln und dann auszutauschen, benötigen die Benutzer mindestens zwei Schlüssel und tauschen diese aus. Wenn es n Benutzer im Unternehmen gibt, benötigt das gesamte Unternehmen n×(n-1) Schlüssel insgesamt. Die Generierung und Verteilung von Schlüsseln wird zum Albtraum der Unternehmensinformationsabteilung. Die Sicherheit des symmetrischen Verschlüsselungsalgorithmus hängt von der Bewahrung des Verschlüsselungsschlüssels ab, aber es ist unmöglich, von jedem, der den Schlüssel im Unternehmen besitzt, zu verlangen, ihn geheim zu halten. In der Regel wird der Schlüssel absichtlich oder unabsichtlich preisgegeben – wenn der Schlüssel vorhanden ist Wird der vom Benutzer verwendete Schlüssel vom Eindringling erhalten, kann der Eindringling alle mit dem Benutzerschlüssel verschlüsselten Dokumente lesen. Wenn das gesamte Unternehmen einen Verschlüsselungsschlüssel teilt, steht die Vertraulichkeit des gesamten Unternehmensdokuments außer Frage.

CA und digitale Zertifikate

Die CA-Zertifizierung, also der elektronische Zertifizierungsdienst, bezieht sich auf die Aktivität zur Bereitstellung einer Authentizitäts- und Zuverlässigkeitsüberprüfung für alle an elektronischen Signaturen beteiligten Parteien.

Eine Zertifizierungsstelle (CA, Certificate Authority) ist eine Organisation, die digitale Zertifikate ausstellt. Es handelt sich um eine maßgebliche Organisation, die für die Ausstellung und Verwaltung digitaler Zertifikate verantwortlich ist und als vertrauenswürdiger Dritter bei E-Commerce-Transaktionen die Verantwortung für die Überprüfung der Gültigkeit öffentlicher Schlüssel im Public-Key-System übernimmt.

---

Ein digitales Zertifikat bezieht sich auf eine digitale Zertifizierung, die die Identitätsinformationen jeder Partei in der Internetkommunikation kennzeichnet, und die Menschen können damit die Identität des anderen im Internet identifizieren.

Die grundlegenden Funktionsprinzipien digitaler Zertifikate spiegeln sich hauptsächlich in Folgendem wider:

Zunächst muss der Absender den Empfänger kontaktieren, bevor er die Informationen sendet, und gleichzeitig den öffentlichen Schlüssel zum Verschlüsseln der Informationen verwenden. Die Informationen befinden sich während des Übertragungsprozesses immer im Zustand des Chiffriertextes, einschließlich der Verschlüsselung an den Empfänger Empfangen, Sicherstellen der Informationen Die Einzigartigkeit der Übertragung: Wenn die Informationen gestohlen oder abgefangen werden, muss der private Schlüssel des Empfängers zur Interpretation der Daten verwendet werden, und die Daten können nicht geändert werden, was auch zur Gewährleistung der Integrität und Sicherheit der Informationen beiträgt .

Zweitens ähnelt die Datensignatur eines digitalen Zertifikats dem Verschlüsselungsprozess: Nachdem die Daten verschlüsselt wurden, kann nur der Empfänger die Dateninformationen öffnen oder ändern, seine eigene Signatur hinzufügen und diese dann an den Absender sowie den privaten Schlüssel des Empfängers übertragen ist einzigartig. Dadurch wird auch die Authentizität und Zuverlässigkeit der Signatur gewährleistet und somit die Sicherheit der Informationen gewährleistet.

https-Prozessverbindungsprozess

Schritt 1: Der Client initiiert eine Anfrage an den Server ( der Client https ist zum Zugriff bereit, aber beide Parteien kennen sich zu diesem Zeitpunkt noch nicht ).

1. Der Client generiert eine Zufallszahl R1 und sendet sie an den Server;
2. Teilen Sie dem Server mit, welche Verschlüsselungsalgorithmen er unterstützt.

Schritt 2: Der Server sendet ein digitales Zertifikat an den Client ( entspricht dem Server, der dem Client seine elektronische Identität mitteilt und welchen Schlüssel er verwenden kann, um mit mir zu kommunizieren ) .

1. Der Server generiert eine Zufallszahl R2;
2. Wählen Sie aus den vom Client unterstützten Verschlüsselungsalgorithmen einen von beiden Parteien unterstützten Verschlüsselungsalgorithmus aus (dieser Algorithmus wird für die nachfolgende Sitzungsschlüsselgenerierung verwendet).
3. Der Server generiert und sendet das Zertifikat, die Zufallszahl R2 und den Sitzungsschlüssel-Generierungsalgorithmus an den Client.

Schritt 3: Der Client überprüft das digitale Zertifikat. ( Der Client bestätigt die Identität des Servers, sendet dann seine eigene elektronische Identität an den Server und teilt mir mit, welchen Schlüssel er verwenden kann, um mit mir zu kommunizieren. )

1. Um die Zuverlässigkeit des Zertifikats zu überprüfen, verwenden Sie zunächst den öffentlichen Schlüssel der Zertifizierungsstelle, um das verschlüsselte Zertifikat zu entschlüsseln. Wenn es entschlüsselt werden kann, bedeutet dies, dass kein Problem mit dem Zertifikat vorliegt. Anschließend werden die Daten durch den bereitgestellten Digest-Algorithmus verarbeitet im Zertifikat, und dann wird der generierte Digest für die Kommunikation mit dem Server verwendet. Zusammenfassungsvergleich gesendet.
   2. Überprüfen Sie die Legitimität des Zertifikats, einschließlich der Frage, ob das Zertifikat widerrufen wurde, ob es abläuft und ob der Domänenname übereinstimmt. Fahren Sie nach dem Bestehen mit dem folgenden Prozess fort: 3. Erhalten Sie den
   öffentlichen Schlüssel des Zertifikats und den Sitzungsschlüsselgenerierungsalgorithmus , und die Zufallszahl R2
   4. Generieren Sie eine Zufallszahl R3.
   5. Verwenden Sie R1, R2 und R3, um einen Sitzungsschlüssel gemäß dem Sitzungsschlüsselalgorithmus zu generieren.
   6. Verschlüsseln Sie die Zufallszahl R3 mit dem öffentlichen Schlüssel des Serverzertifikats und senden Sie ihn an den Server.

Schritt 4: Der Server erhält den Sitzungsschlüssel ( der Server bestätigt die Identität des Clients, und dann kennen beide Parteien dreimal die Zufallszahl und den geheimen Schlüsselalgorithmus, und die Konversation kann anschließend normal verschlüsselt werden) .

1. Der Server verwendet den privaten Schlüssel, um die vom Client gesendete Zufallszahl R3 zu entschlüsseln
2. Verwenden Sie R1, R2, R3, um einen Sitzungsschlüssel gemäß dem Sitzungsschlüsselalgorithmus zu generieren

Schritt 5: Verschlüsselte Sitzung zwischen Client und Server

1. Der Client sendet verschlüsselte Daten an den Server

     发送加密数据：客户端加密数据后发送给服务端。
   

2. Der Server antwortet dem Client

      解密接收数据：服务端用会话密钥解密客户端发送的数据;                                                                加密响应数据：用会话密钥把响应的数据加密发送给客户端。
   

3. Der Client entschlüsselt die vom Server geantworteten Daten

       解密数据：客户端用会话密钥解密响应数据;
   

————————————————
Copyright-Erklärung: Dieser Artikel ist ein Originalartikel des CSDN-Bloggers „purpleFairyx“. Gemäß der CC 4.0 BY-SA-Copyright-Vereinbarung fügen Sie bitte den Original-Quelllink und dies bei Erklärung zum Nachdruck.
Ursprünglicher Link: https://blog.csdn.net/m0_46364778/article/details/124884079

————————————————
Copyright-Erklärung: Dieser Artikel ist ein Originalartikel des CSDN-Bloggers „purpleFairyx“. Gemäß der CC 4.0 BY-SA-Copyright-Vereinbarung fügen Sie bitte den Original-Quelllink und dies bei Erklärung zum Nachdruck.
Ursprünglicher Link: https://blog.csdn.net/m0_46364778/article/details/124884079

Das Springboot-Projekt startet https

baidu/google:

Zertifikatserstellung:

keytool -genkey -alias tomcat  -storetype PKCS12 -keyalg RSA -keysize 2048  -keystore keystore.p12 -validity 3650

wichtige Konfiguration

import org.apache.catalina.Context;
import org.apache.catalina.connector.Connector;
import org.apache.tomcat.util.descriptor.web.SecurityCollection;
import org.apache.tomcat.util.descriptor.web.SecurityConstraint;
import org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory;
import org.springframework.boot.web.servlet.server.ServletWebServerFactory;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
/**
 * @Author mubi
 * @Date 2023/7/17 23:09
 */
@Configuration
public class ServletWebServerConfiguration {
    
    
    @Bean
    public ServletWebServerFactory servletContainer() {
    
    
        TomcatServletWebServerFactory tomcat = new TomcatServletWebServerFactory() {
    
    
            @Override
            protected void postProcessContext(Context context) {
    
    
                // Due to CONFIDENTIAL and /*, this will cause Tomcat to redirect every request to HTTPS.
                // You can configure multiple patterns and multiple constraints if you need more control over what is and is not redirected.
                SecurityConstraint constraint = new SecurityConstraint();
                constraint.setUserConstraint("CONFIDENTIAL");
                SecurityCollection collection = new SecurityCollection();
                collection.addPattern("/*");
                constraint.addCollection(collection);
                context.addConstraint(constraint);
            }
        };
        tomcat.addAdditionalTomcatConnectors(httpConnector());
        return tomcat;

    }

    @Bean
    public Connector httpConnector() {
    
    

        Connector connector = new Connector("org.apache.coyote.http11.Http11NioProtocol");
        connector.setScheme("http"); // 使用http协议
        connector.setPort(8080);  // HTTP监听端口
        // if connector.setSecure(true),the http use the http and https use the https
        // else if connector.setSecure(false),the http redirect to https;
        connector.setSecure(true);
        // redirectPort The redirect port number (non-SSL to SSL)
        connector.setRedirectPort(8449); // 重定向端口
        return connector;
    }
}

application.properties lauten wie folgt

#https
server.port=8449
server.ssl.key-store=classpath:keystore.p12
server.ssl.key-store-password=123456
server.ssl.keyStoreType=PKCS12
server.ssl.keyAlias=tomcat

Der Start gelingt wie folgt:

Wenn direktes HTTP auf den https-Port zugreift, ist der Fehler wie folgt

Der erste Zugriff auf https wird wie folgt angezeigt.

Fahren Sie fort, und der richtige Zugriff erhält das Ergebnis:

Das lokal generierte Zertifikat können Sie wie folgt einsehen:

Sicheres Zertifikat, ähnlich wie Baidu wie folgt

Wireshark analysiert den https-Prozess

Der Unterschied zwischen http und https:

SSL/TLS-Protokollprozess

Das Folgende sind die verschlüsselten Daten, die übertragen werden, nachdem der Paketerfassungs-Handshake der zugreifenden Station b abgeschlossen ist