boweeko
Goto Top

Ist eine SSL Verschlüsselung über einen DDNS -Anbieter möglich?

Hallo ihr Administratoren,

ich bin gerade über eine Aussage unseres Webproviders überrascht, der meine Methode, ein Intranet über das Internet zugänglich zu machen, als fehlerhaft einstuft.
Aber lest selbst...

Ausgangslage:
lokaler Webserver: IIS7
Internetanschluss: DSL (dyn. IP)
Dyn-DNS-Service: no-ip.com
Webspacehoster: eigene Domain für unsere Internetpräsenz

Wir betreiben in unserem lokalen Netzwerk eine Intranetlösung. Nun besteht der Wunsch, auch von zu Hause bzw. unterwegs auf das Intranet zu greifen zu können. Dazu habe ich eine Subdomain bei unserer von einem Webprovider gehosteten Domain angelegt (z.B.: intranet.domainname.de). Danach eine Weiterleitung von der Subdomain auf eine DDNS-Adresse mit https(z.B. https://subdomain.no-ip.info:1234/intranet). Der Router nimmt die Anfrage an und routet den eingehenden Port auf den Webserver. Auf dem Webserver ist ein SSL-Zertifikat installiert das für die Domain intranet.domainname.de ausgestellt ist. Es kommt zwar zu einer Fehlermeldung weil das Zertifikat ja intranet.domainname.de statt https://subdomain.no-ip.info:1234/intranet erwartet.
Eine SSL Verbindung wird aber trotzdem aufgebaut. Glaubte ich zu mindestens bis jetzt.

Denn unser Webprovider schrieb folgendes dazu:

Sie bräuchten dann bei uns eine eigene IP, und auch noch ein
SSL_CERT.
Dann kommt im Browser zwar keine Warnmeldung und die Verbindung vom
Browser zu intranet.domainname.de ist verschlüsselt.
Aber von intranet.domainname.de zu https://subdomain.no-ip.info:1234/intranet ist die Verbindung
unverschlüsselt. Davon merkt der Besucher zwar nichts, aber die Verbindung
ist nicht gesichert, daher ist das so nicht ratsam.
Soll die auch verschlüsselt sein, müssen Sie für https://subdomain.no-ip.info:1234/intranet ein
Zertifikat haben.



Meine Frage dazu:
Ist das wirklich der Fall, dass obwohl in den verwendeten Browsern z.B. das Sicherheitsschloss anzeigt, dass die Verbindung über https bzw. SSL-Zertifikat gesichert ist, keine Verschlüsselung erfolgt?
Wenn das der Fall wie sichere ich dieses Szenario am besten ab?

Content-Key: 189026

Url: https://administrator.de/contentid/189026

Ausgedruckt am: 29.03.2024 um 10:03 Uhr

Mitglied: brammer
brammer 02.08.2012 um 15:20:49 Uhr
Goto Top
Hallo,

schon mal über eine saubere VPN Lösung nachgedacht?

brammer
Mitglied: Boweeko
Boweeko 02.08.2012 um 15:51:06 Uhr
Goto Top
Hallo brammer,

VPN ist in meinen Augen keine Option, da unsere Mitarbeiter ihre privaten Rechner zur Einwahl benutzen müssten. Und VPN ist da komplizierter als einfach eine URL in den Browser einzutippen.

Die Hürden sollen so niedrig wie möglich sein.

Boweeko
Mitglied: maretz
maretz 02.08.2012 um 16:25:15 Uhr
Goto Top
Nun - generell wirst du dir damit nur noch mehr Probleme ins Haus holen als du willst... Du vermischt da SSL-Verbindungen, diverse Ports,... WENN es denn schon eine direkte Verbindung zum Web geben soll dann gib den Kollegen gleich den Link auf die interne Seite. Denn deine ganze Zertifikats-Lösung bringt ja nix wenn jeder der die URL auf eurem Server kennt eh schon auf euer Intranet zugreiffen kann...

Wobei ich auch empfehlen würde eine vernünftige VPN-Lösung zu nehmen... Du kannst heute auch VPN-Verbindungen exportieren - dann sind die mit nem Doppelklick praktisch nutzbar (z.B. ShrewSoft VPN-Client). Wem das jetzt noch zu komplex ist - dem würde ich vermutlich keinen externen Zugriff einrichten wollen... wer weiss ob da nicht der Virenscanner auch zu komplex war und plötzlich die Zugangsdaten - keylogger sei dank! - schon 2 Minuten später im Web die Kreise ziehen...
Mitglied: filippg
filippg 03.08.2012 um 00:37:02 Uhr
Goto Top
Hallo,

irgendwer wirft da etwas durch einander - du oder dein Provider.
Unter DDNS versteht man i.A. nur DNS-Einträge. Also subdomain.no-ip.info -> 10.11.12.13. Will jemand auf den Server zugreifen, so baut er eine _direkte_ Verbindung zu ihm auf - es gibt also keine zwei Teilstrecken von denen eine verschlüsselt und eine unverschlüsselt ist. Die Weiterleitung auf deiner Website veranlasst den Browser, eine neue Verbindung aufzubauen.
Von zwei Verbindungen würde man etwa bei Proxying sprechen. Der Anwender verbindet sich zu deinem Webserver, _dieser_ fragt im Hintergrund die Inhalte von deinem lokalen Server ab. (damit wäre also die zweite Verbindung ggf. unverschlüsselt, obwohl dein Browser das Schloss anzeigt).
Letzteres Szenario ist eher unwahrscheinlich.
Aber der IIS produziert doch Logfiles. Und in diesen ist auch der Port, über den eine Anfrage reinkommt, angegeben. Und im IIS lässt sich dann auch prüfen, ob auf diesem Port HTTP oder HTTPS gebunden ist. Daneben könnte es ohnehin geschickt sein, unbenutzte Ports (80) auf der Firewall eingehend zu blockieren (wenn er eh nicht genutzt werden soll...). Und dann hast du auch Sicherheit. Absolute Sicherheit bringt im Zweifelsfall auch ein tcpdump (Wireshark, MS NetMon).

Gruß

Filipp