SSL-Zertifikate für "t-ipconnect.de" Subdomains - ist dies OK?
vor 10 Jahren
Hallo,
wie vermutlich bei anderen Anbietern auch haben die von der Telekom vergebenen IPv4- und IPv6-Adressen einen PTR-Record, der auf einen Hostnamen einer Domain des Unternehmens zeigt, der wiederrum auf die IP-Adresse zeigt. Beispielsweise hat die von der Telekom vergebene IP 217.238.15.1 einen PTR-Record für "pD9EE0F01.dip0.t-ipconnect.de" (abrufbar unter "1.15.238.217.in-addr.arpa"):
# nslookup 217.238.15.1 Server: 192.168.170.2 Address: 192.168.170.2#53 Non-authoritative answer: 1.15.238.217.in-addr.arpa name = pD9EE0F01.dip0.t-ipconnect.de.
# nslookup pD9EE0F01.dip0.t-ipconnect.de
Server: 192.168.170.2
Address: 192.168.170.2#53
Non-authoritative answer:
Name: pD9EE0F01.dip0.t-ipconnect.de
Address: 217.238.15.1
Nun gibt es ja seit kurzem Let’s Encrypt, eine neue CA, die kostenlose domainvalidierte Zertifikate ausstellt, um die Verbreitung von TLS zu fördern. Bei Let’s Encrypt kann man z.B. für den manuellen Modus mit OpenSSL einen CSR erstellen, der als Common Name im Subject sowie als Subject-Alternative-Name einen Hostnamen enthält, für den man das Zertifikat bekommen möchte; dies kann auch eine Subdomain sein wie "aa.bb.cc.de".
Die Validierung, dass man die Domain tatsächlich kontrolliert, erfolgt dann beispielsweise dadurch, dass man eine Datei mit einem bestimmten von der CA festgelegten Inhalt auf seinem Webserver platzieren muss; anschließend kann man das Zertifikat erstellen.
Dadurch, dass man nur dern Hostnamen (also z.b. die Subdomain) und nicht die Hauptdomain verifizieren muss, kann man nun also beispielsweise für den aktuellen Hostnamen ein Zertifikat erstellen.
Interessant hierbei ist, dass manche Browser die Subdomain-Anteile grau färben und damit die Hauptdomain als wichtiger erscheint, und beispielsweise Firefox beim Klick auf das Schloss nur die Hauptdomain anzeigt:
Bei der Domain "t-ipconnect.de" sehe ich das jetzt nicht ganz so problematisch, da die Domain nicht unbedingt bekannt ist und beim Aufruf von http://t-ipconnect.de/ auch keine Webseite kommt, da kein A- bzw. AAAA-Record vorhanden ist. Wenn man die Domain auf Denic abfragt, bekommt man aber halt "Deutsche Telekom AG" angezeigt.
Interessanter wäre das beispielsweise bei Kabel Deutschland, wo man bei einer IP wie 178.25.120.1 den Hostnamen "ipb2197801.dynamic.kabel-deutschland.de" bekommt, bei dem die Hauptdomain (kabel-deutschland.de) ja eine ganz normale Webseite ist. Durch die Art der TLS-Anzeige im Firefox könnte ein User den Eindruck gewinnen, er wäre auf der Kabel-Deutschland-Seite, deren Authentizität durch das Zertifikat bestätigt ist, obwohl es nur irgend ein von einem Kunden betriebener Webserver ist.
Zusätzlich ist es ja bei vielen deutschen Internetanbietern so, dass die IP nach jedem Einwahlvorgang wechselt, während die Domain-Validierung bei Let’s Encrypt 10 Monate gültig ist, man also weiterhin Zertifikate für den Hostnamen ausstellen kann, obwohl die IP längst jemand anderes hat.
Auf Let’s Encrypt wurde dies auch schon diskutiert. Soweit ich es verstanden habe, soll es für Domaininhaber allerdings die Möglichkeit geben, das Ausstellen von SSL-Zertifikaten für Subdomains zu sperren.
Ich wollte deshalb fragen, wie die Telekom dies sieht.
Danke!
Hinweis:
Hinweis:
625
0
0
Das könnte Sie auch interessieren
Kaufberatung anfragen
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Angebote anzeigen
Informieren Sie sich über unsere aktuellen Internet-Angebote.
vor 10 Jahren
ich muss gestehen, dass ich in diesem Thema gar nicht drin bin. Ihre Anfrage habe ich einmal bei meinen Kollegen in der zuständigen Abteilung platziert. Sobald ich eine Rückmeldung erhalte melde ich mich hier zurück.
Viele Grüße
Heike J.
0
0
vor 10 Jahren
Verstehe ich dich richtig? Du hast dir lokal einen Apachen installiert und diesen über den Cannoncial Name deiner aktuell zuordneten IP-Adresse aufgerufen? Also das klappte hast du dazu ein Zertifikat ausgestellt und dich gefreut.
Jetzt vermutest du, das man etwas Mißbrauchen könnte, weil ja die IP-Adresse und damit auch der Cannoncial Name dynamisch zugewiesen wird?
In dem Moment, wo du die IP nicht mehr hast, ist es ja gar nicht mehr möglich die https Verbindung zu dieser Subdomain aufzubauen. Selbst wenn der nächste "Inhaber" der IP zufällig selber auch einen Webserver am laufen hat, wäre der Aufruf mit deinem Zertifkat nicht möglich.
Das ganze ist also nicht nur Sinnlos sondern auch Problemlos. Oder hab ich da was falsch verstanden?
0
0
von
vor 10 Jahren
Doch ich hab dich richtig verstanden ;O)
Aus praktischer Sicht ist das natürlich ziemlich unwahrscheinlich, da man (nehme ich mal an) nicht vorhersehen kann wer als nächstes eine bestimmte IP bekommt, und dann auch noch am richtigen Ort im Netzwerk sein müsste, um den Datenverkehr zu manipulieren; aber es bleibt trotzdem ein theoretisches Problem, das in dem verlinkten Let's-Encrypt-Thread glaube ich auch diskutiert wurde.
Aus praktischer Sicht ist das natürlich ziemlich unwahrscheinlich, da man (nehme ich mal an) nicht vorhersehen kann wer als nächstes eine bestimmte IP bekommt, und dann auch noch am richtigen Ort im Netzwerk sein müsste, um den Datenverkehr zu manipulieren; aber es bleibt trotzdem ein theoretisches Problem, das in dem verlinkten Let's-Encrypt-Thread glaube ich auch diskutiert wurde.
Das ist auch deswegen ziemlich unwahrscheinlich, weil jeder der einen Server hinter einer dynamischen IP-Adressen betreibt, dazu einen DynDNS nutzt (en sollte) und wenn überhaupt die Subdomain des DynDNS Anbieters mit einem Zertifikat verknüpfen würde. Das ganze scheint mir doch arg konstruiert zu sein.
Zertifikate für Subdomains sind aber doch nichts ungewöhnliches. Diese Seite hier, z.B. hat auch ein Zertifikat für telekomhilft.telekom.de.
Letztendlich müsste aber ja Let's Encrypt als Zertifizierter eine solche scheinbare Sicherheitslücke unterbinden, damit die Zertifikate dieses Anbieters Vertrauenswürdig bleiben. Also im eigenen Interesse. Und das geht ja auch, den die WHOIS-Einträge für diese Domains und IP-Adressen weisen ja eindeutig darauf hin das es sich dabei nicht um eigene Domains / Subdomains handelt bzw. um dynamische Adressen....
0
von
vor 10 Jahren
Hallo,
Das ist auch deswegen ziemlich unwahrscheinlich, weil jeder der einen Server hinter einer dynamischen IP-Adressen betreibt, dazu einen DynDNS nutzt (en sollte) und wenn überhaupt die Subdomain des DynDNS Anbieters mit einem Zertifikat verknüpfen würde. Das ganze scheint mir doch arg konstruiert zu sein.
Ja, das mag sein. Dennoch ist das meiner Ansicht nach kein Grund, die Thematik "unter den Teppich zu kehren" (oder wie man sagt).
Zertifikate für Subdomains sind aber doch nichts ungewöhnliches. Diese Seite hier, z.B. hat auch ein Zertifikat für telekomhilft.telekom.de.
Ich glaube du hast mich immer noch nicht 100%ig verstanden...
Mir geht es ja nicht um Zertifikate für Subdomains an sich, wie es beispielsweise bei "telekomhilft.telekom.de" der Fall ist. Dort ist es ja so, dass die Webserver unter "telekomhilft.telekom.de" auch zur Telekom mit gehören, und für solche Domains ist es normalerweise auch so, dass diese längere Zeit (Jahre) nicht den Besitzer wechseln.
Hingegen ist es bei den dynamischen Hostnamen so, dass ein Webserver, der unter diesem Namen erreichbar ist, nicht zur Telekom (oder einem entsprechenden anderen Anbieter) gehört, sondern halt dem Kunden (das meinte ich im zweiten Punkt) und die Domain nicht mehrere Monate oder Jahre für einen bestimmten Kunden reserviert ist, sondern am nächsten Tag schon wieder ein andere Kunde haben kann (meinte ich im ersten Punkt).
Warum ich das ausgerechnet im Zusammenhang mit Let's Encrypt schreibe, ist, dass mir bisher noch keine CA bekannt war, bei der es reicht, auf einer (beliebigen) Subdomain über HTTP bestimmten Inhalt bereitzustellen, um schon ein Zertifikat zu bekommen (kann sein dass das bei anderen CAs auch schon so möglich war, nur kannte ich halt noch keine).
Wenn ich beispielsweise bei StartSSL ein Zertifikat erstellen wollte für "sub.example.org", müsste ich zuerst bestätigen, dass ich Inhaber von "example.org" bin, indem sie eine Email an "postmaster@example.org" schicken. Danach kann man eine zusätzliche Subdomain angeben.
Für einen Hostnamen wie "xyz.t-ipconnect.de" könnte man hier also gar kein Zertifikat erstellen, da einem die Hauptdomain "t-ipconnect.de" nicht gehört, sondern der Telekom. Auch wenn man nur die Subdomain "xyz.t-ipconnect.de" bestätigen müsste, würde es noch nicht gehen, da man für diese keinen MX-DNS-Record setzen könnte, der zum Erhalt der E-Mail notwendig ist, da der zuständige DNS-Server von der Telekom verwaltet wird (und bei Let's Encrypt ist keine zusätzliche DNS-Challenge notwendig)
Auf der anderen Seite ist das schon vorteilhaft, da man nun halt auch einfach Zertifikate z.B. für Dyndns-Subdomains erstellen kann, auch wenn man keinen Zugriff auf den DNS-Server hat.
Letztendlich müsste aber ja Let's Encrypt als Zertifizierter eine solche scheinbare Sicherheitslücke unterbinden, damit die Zertifikate dieses Anbieters Vertrauenswürdig bleiben. Also im eigenen Interesse. Und das geht ja auch, den die WHOIS-Einträge für diese Domains und IP-Adressen weisen ja eindeutig darauf hin das es sich dabei nicht um eigene Domains / Subdomains handelt bzw. um dynamische Adressen....
Ja, da hast du recht.
Ich habe auch nichts dagegen, dass man für solche Subdomains Zertifikate ausstellen kann - was mich aber eben interessiert, ist, ob die Telekom was dagegen hat (falls ja, kann sie einen CAA-Record angeben, der das verhindert) . Deswegen meine Nachfrage.
Danke!
0
von
vor 10 Jahren
0
vor 10 Jahren
folgende Info habe ich von meinen Kollegen erhalten:
Die Deutsche Telekom betreibt unter *.t-ipconnect.de keinen Webdienst, insofern sehen wir kein Phishing -Risiko.
Prinzipiell unterstützen wir den Einsatz von https und sehen keine reale Bedrohung für uns oder unsere Kunden.
Welche Zertifikate derzeit für *.dip0.t-ipconnect.de ausgestellt sind, kann man u. A. hier einsehen:
https://crt.sh/?Identity=%dip0.t-ipconnect.de%&iCAID=7395
Viele Grüße
Heike J.
0
0