Also wenn der Proxy die IP und den Port kennt, dann kann er doch die Pakete dorthin weiterleiten und sobald das Zertifikat vom Server gesendet wird, den Hostnamen verwenden. Wenn dieser nicht gesperrt werden soll, kann die Verbindung doch über das originale Zertifikat erfolgen. Somit ist der Proxy doch transparent. Erkennen kann man ihn doch erst dann, wenn er selbst ein dynamisches Zertifikat ausstellt.
HTTPS bzw. TLS Proxy Server
(Themenstarter)
Anmeldungsdatum: Beiträge: 130 |
|
Ehemaliger
Anmeldungsdatum: Beiträge: 17447 |
Der Proxy bekommt davon aber doch nichts mit, du leitest ja beim Transparenten HTTP Proxy alles um was über extern raus geht und nach Port 80 will. Dann wird ein NAT gemacht (bei IPv6 nicht vorgesehen, ätsch) und der Request/Connect an den Proxy gepackt. Bei HTTP sieht man über die normalen HTTP Header was das Ziel der Verbindung war. Bei HTTPS hat man ein Problem: Nach dem NAT ist die IP nicht mehr vorhanden, die wurde ja eben wegen NAT umgeschrieben. Du hast also einen SSL Handshake ohne Host, wie willst du diesen zustellen? tl;dr Version dieser Diskussion:
mfg Stefan Betz |
(Themenstarter)
Anmeldungsdatum: Beiträge: 130 |
Der, der die Pakete umleitet macht ein NAT, klar. Aber es muss doch irgendwie ein Möglichkeit geben, den wirklichen Host und Port in dem Paket mitzugeben. Mittels Paketmanipulation. |
Ehemaliger
Anmeldungsdatum: Beiträge: 17447 |
Der Port ist bei HTTPS 443, das ist recht einfach. Der Kernel kann Pakete markieren, ob es einen Proxy gibt welcher derartige Markierungen im Userspace annimmt ist mir nicht bekannt. Aber selbst wenn das geht ist mit IPv6 erstmal Schluss damit. mfg Stefan Betz |
(Themenstarter)
Anmeldungsdatum: Beiträge: 130 |
Aber was hat das Ganze mit IP zu tun. Ich meine es muss doch möglich sein, über TCP oder SOCKS diese wirkliche Ziel-IP mitzugeben. |
Ehemaliger
Anmeldungsdatum: Beiträge: 17447 |
TCP ist oberhalb der IP, und IP hat eben die IP Adressen damit TCP die nicht haben muss. Wäre sonst doch Redundant, und Informatiker hassen (bis auf Microsoft, die codieren zusätzlich IPs in höhere Protokolle) Redundanzen außer bei Backups. SOCKS ist ein Proxy Protokoll, da bekommst du natürlich die Infos. Genau genommen bekommst du bei SOCKS einen Hostname und den Zielport, damit kannst du dann auch schon filtern. Das ist dann aber kein Transparenter Proxy, sondern halt nur ein Proxy. Aber schau dir mal Link an, vielleicht ist das was du suchst. mfg Stefan Betz |
(Themenstarter)
Anmeldungsdatum: Beiträge: 130 |
Wenn ich das richtig verstanden habe, dann läuft redsocks auf dem Weiterleitungssystem und verpackt dort die Daten in das SOCKS-Protokoll und liefert Ziel-IP und Ziel-Port mit. Anschließend wird das an einen SOCKS-Proxy gesendet. Richtig? |
(Themenstarter)
Anmeldungsdatum: Beiträge: 130 |
Ist es möglich, mit einem einfachen Paketfilter das Zertifikat abzufangen und ggf. einen TLS-Error zurückzugeben? |
(Themenstarter)
Anmeldungsdatum: Beiträge: 130 |
Auch wenn niemand mehr antwortet, erachte ich es als richtig meine Lösung als Abschluss zu veröffentlichen. TLS-Pakete werden umgeleitet und der Aufrufende bekommt ein Fake-Zertifikat. Will dieser sicher surfen, muss er einen HTTPS bzw. TLS/SSL-Proxy einstellen, der dann den aufgerufenen Host mittels "CONNECT"-Methode mitteilt. Funktioniert soweit super! |