C# proxy ssl/tls Passthrough ohne Zertifikat

Question

Dies ist das Problem.

Ich habe eine https Anfrage. Die Anfrage wird als SSL/TLS-Anfrage gesendet (nicht die CONNECT ...., die von einem Browser mit dem Proxy-Setup kommt).

Ich muss einen Proxy in C# schreiben, der eine bestimmte https://foo.com/foo.htm Anfrage blockiert, aber durch https://foo.com/anything_else.htm geht.

Ich kann diese feine machen einen MITM-Angriff mit einem neuen Zertifikat erstellen etc etc.

Aber Im frage mich jetzt, ob es eine einfache Möglichkeit, ohne Verwendung eines MITM Angriff dieses Im fehlenden zu tun, wie ich es nicht nötig haben, um Entschlüsseln Sie die Daten. Ich muss nur die URI/Datei kennen.

Ich kann einfach nur Streams übertragen, aber ich möchte wissen, ob es eine einfache Möglichkeit gibt, die Streams zu übertragen, nachdem ich den URI und die Datei gelesen habe.

Ich kann etwas ausgefallenen Code schreiben, um die TCP-Anfrage auseinander zu ziehen, und das ist, was ich tun muss.

Irgendjemand irgendwelche Ideen, bevor ich diesen Weg gehen. Denken Sie daran, dass keine CONNECT-Anfrage vorliegt. Nur direkte SSL/TLS.

Der Hauptgrund dafür ist, es nicht zu schaffen selbst signierten Zertifikate usw.

Vielleicht gerade einfachere Dinge macht seine sogar möglich, das reale Zertifikat irgendwie vom Server Ende zu verwenden, wie ich einen der nicht brauche nicht zu entschlüsseln Kopfdaten.

Ich finde die Netzwerkseite von C# ist nicht sehr gut dokumentiert und ein wenig überall.

Gerade als Referenz kann ich den URI aus dem TcpClient erhalten mit:

IPEndPoint ipEndPoint = (IPEndPoint)clientTcpClient.Client.RemoteEndPoint; 

IPAddress ipAddress = ipEndPoint.Address; 

// Get the hostname. 
IPHostEntry ipHostEntry = Dns.GetHostEntry(ipAddress); 
String hostName = ipHostEntry.HostName; 

// Get the port. 
Int32 port = ipEndPoint.Port; 

Aber nicht die angeforderte Seite.

Answer 1

Während der Zielhostname im TLS-Handshake als SNI-Erweiterung oder durch Analyse des vom Server zurückgegebenen Zertifikats sichtbar ist, ist die Pfadkomponente der URL nur in der HTTP-Anforderung enthalten. Da diese HTTP-Anfrage erst nach dem TLS-Handshake erfolgt und die Anfrage somit bereits verschlüsselt ist, können Sie nicht auf den vollständigen Pfad zugreifen, ohne die Anfrage zu entschlüsseln. Dies bedeutet, dass das Blockieren des Zugriffs auf einen bestimmten Pfad nicht möglich ist, ohne dass ein SSL-Benutzer in der Mitte vorhanden ist, und somit ein Zertifikat für die Zielsite, die dem Mann in der Mitte gehört und dem Client vertraut.

Nicht, dass dies auch für CONNECT-Anforderungen gilt, da diese Anforderungen nur den Zielhostnamen enthalten, die Pfadkomponente jedoch wiederum nur in der verschlüsselten HTTP-Anforderung in dem von CONNECT erstellten Tunnel enthalten ist.