Hallo zusammen,
ich bin gerade dabei den WebProxy so einzurichten, dass dieser per WPAD verteilt wird.
Dies funktioniert auch zum Teil. Wenn ich einen Browser nutze, welcher dem Zertifikat der OPNsense vertraut, kann dieser sich die Wpad Datei problemlos holen und damit arbeiten.
Ich kann nur im fertigen System nicht jeden Client sagen, dass er dem Zertifikat vertrauen soll.
Gibt es eine möglichkeit, dass die Wpad Datei auch per http abrufbar ist?
Wenn ich im Internet Explorer "http://ipderFirewall/wpad.dat" eingebe, werde ich wieder auf "https://ipderFirewall/wpad.dat" geleitet, und habe dann wieder das Zertifikatsproblem.
Vielleicht hatte hier ja jemand schon ein ähnliches Problem
Beste Grüße :)
Nimm doch nen let's Encrypt certificate auf deiner Firewall.
Gesendet von meinem SM-N950F mit Tapatalk
Quote from: Sven-J on March 05, 2019, 02:04:02 PM
Nimm doch nen let's Encrypt certificate auf deiner Firewall.
Danke dir :)
gibts dazu vielleicht eine einfach zu verstehende Anleitung?
Außerdem hängt die FW "intern" hinter einem anderen Router und hat somit nichts kein öffentlichen Namen worauf ich das Zertifikat austellen könnte. Oder irre ich mich Total? :D
Ich hab aufm englischen Post geantwortet ...
danke:)
habe jetzt erstmal das Web Interface auf http umgestellt, damit läuft es.
Bin jetzt gerade dabei, dass auch Android Geräte die wpad.dat nutzen.
Aber makiere das hier erstmal als gelöst :)
Bin auch an der Umstellung. Dachte aber, mal gelesen zu haben, dass die Android-Geräte eine proxy.pac brauchen und mit wpad.dat nicht zurechtkommen?
Gruess
Roger
Das kann auch sein, weiß aber nicht wie man dies in der OPNsense einrichtet.
Ich werde einfach für alle nicht Windows Geräte ein extra Netz machen, was nicht über den Proxy läuft, da es hauptsächlich darum geht die Wndows Geräte zu Filtern.
Quote from: ruggerio on March 13, 2019, 12:32:09 PM
Bin auch an der Umstellung. Dachte aber, mal gelesen zu haben, dass die Android-Geräte eine proxy.pac brauchen und mit wpad.dat nicht zurechtkommen?
proxy.pac ist nur ein alternativer Name, der traditionell in der DHCP-Option 252 verwendet wurde. Inhalt ist derselbe, wie in der
wpad.datQuoteBei der DNS-Abfrage lautet der Pfad der Konfigurationsdatei immer wpad.dat. Beim DHCP-Protokoll kann jegliche URL benutzt werden. Aus traditionellen Gründen lauten die Namen der PAC-Dateien oft proxy.pac (natürlich werden Dateien dieses Namens von der WPAD DNS-Suche ignoriert).
https://de.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol (https://de.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol)
Ich hatte früher im DHCP auch
proxy.pac und diese als Hardlink auf
wpad.dat. Aber mal ehrlich: warum die Mühe machen, statt die URL im DHCP auch einfach mit
wpad.dat zu setzen?
Wenn ich beim Android Handy manuell die wpad URL eingepflegt habe, ging trotzdem nichts üer den Proxy.
Wird die wpad.dat denn abgefragt? Was sagen die Logs des Webservers? IP des Androidgeräts muss auftauchen. Nutzt du ipv6? Nicht das du in deiner wpad.dat nur ipv4 Adressen handhabst.
1) wpad.dat geht nicht bei Android: falsch
2) Android mit https geht nicht: richtig
Lösung, damit die Android-Geräte die WPAD.dat ziehen: Umstellung Weboberfläche opnsense auf http. Bei mir gehts zumindest korrekt. 1000gratisproben.com war ein gutes Testobjekt :)
url bei automatisch im Android-Proxy eintragen: http://url_opnsense/wpad.dat :-\
Also ist demnach bei Android kein Transparenter HTTPS Proxy ohne das verteilen von Zertifikaten möglich ? :)
von mobil gesendeten, daher kurz :)
Bei keinem Betriebssystem sollte ein transparenter SSL-Proxy funktionieren ohne auf den Clients entsprechende Zertifikate zu haben. Alles andere würde den Sinn und Zweck von Zertifikaten ad absurdum führen.
Aber Du kannst es rein auf SNI filtern. Dann steht der unverschlüsselte Servername zum Filtern zur Verfügung und der restliche Traffic wandert verschlüsselt mit dem Orginalzertifikat zwischen Webserver und Client. Da benötigt es auf Clients keine zusätzlichen Proxyzertifikate.
Sorry !
Meinte ein Proxy der per wpad sozusagen ja im Android eingestellt wird :)
von mobil gesendeten, daher kurz :)
@hbc das ist inzwischen auch nicht mehr korrekt. Mit TLS 1.3 kommt ESNI (Encrypted Server Name Indication) - vorausgesetzt, der Server will mit ESNI angesprochen werden (DNS).
Quote from: fabian on March 17, 2019, 09:36:29 PM
@hbc das ist inzwischen auch nicht mehr korrekt. Mit TLS 1.3 kommt ESNI (Encrypted Server Name Indication) - vorausgesetzt, der Server will mit ESNI angesprochen werden (DNS).
@fabian: Ja, aber dann muß man erst recht das Proxyzertifikat auf die Clients verteilen. Transparenter SSL-Proxy ohne Zertifikate auf Clients darf per Design nicht funktionieren - sonst kann man sich selbige sparen.
QuoteSorry !
Meinte ein Proxy der per wpad sozusagen ja im Android eingestellt wird :)
@lfirewall1243: Nur weil die
wpad.dat per http bezogen wird, bedeutet es doch nicht, das man damit nicht die Einstellungen für andere Protokolle, wie z.B. HTTPS, festlegen kann. So habe ich das zumindest interpretiert.
In der
wpad.dat kann Du ja pro Protokoll einen Proxy angeben. z.B. hier einen für HTTP und HTTPS (Proxy tunnelt SSL dann über CONNECT) und FTP geht über SOCK-Server:
function FindProxyForURL(url, host){
if ( url.substring(0, 5) == "http:" || url.substring(0, 6) == "https:") {
return "PROXY webcache.local:3128";
}
else if (url.substring(0, 4) == "ftp:"){
return "SOCKS sockssrv.local:1080";
}
return "DIRECT";
}
Quote@lfirewall1243: Nur weil die wpad.dat per http bezogen wird, bedeutet es doch nicht, das man damit nicht die Einstellungen für andere Protokolle, wie z.B. HTTPS, festlegen kann. So habe ich das zumindest interpretiert.
In der wpad.dat kann Du ja pro Protokoll einen Proxy angeben. z.B. hier einen für HTTP und HTTPS (Proxy tunnelt SSL dann über CONNECT) und FTP geht über
Wenn dass hinterlegt ist, muss man demnach ja kein Zertifikat installieren. Richtig? :)
Genau. Solange Du den Haken bei Only log SNI gesetzt hast und somit keine Verschlüsselung aufbrichst, brauchst Du nichts hinterlegen.
Die Anwendungen, die wpad.dat auswerten, melden sich eh korrekt beim Proxy und bauen über CONNECT Tunnel auf, bei denen mit transparenter Umleitung wird nur SNI ausgewertet. Darüber kann z.B. Blackliste das Ziel filtern und Traffic wird dann verschlüsselt zwischen Client und Server direkt ausgetauscht.