bye bye SSL-Proxy nach 1und1-Manier?

[bernostern]

Hallo,

es gibt die Möglichkeit, in der openssl.cnf den Parameter subjectAltName auf viele unterschiedl. Domains zu setzen, die dann alle mit SSL-Verschlüsselung funktionieren.

Code: Select all

subjectAltName = DNS:http://www.domain1.com,DNS:*.domain2.com

Danach ist dann für jede dieser Domains ein VirtualHost mit SSL Verschlüsselung möglich. Zwar nur mit einem einzigen Cert (glaub ich), aber man braucht im Grunde den SSL-Proxy von 1und1 nicht mehr, da der ständig Mucken mit Verzeichnissen und Pfaden innerhalb von Scripten macht (siehe Confixx-WebFTP usw.). Mir persönlich geht es nur um Verschlüsselung, nicht um gültige Zertifikate.

Kennt jemand diesen Parameter und verwendet ihn, oder kann mir jemand abraten ihn zu benutzen?

Danke und schönen Gruß,
Bern

[freeman76]

Hi,
habe mit folgender SSL-Proxy Konfiguration keinerlei Probleme mit Pfaden etc:

Code: Select all

LoadModule proxy_module /usr/lib/apache/1.3/libproxy.so
LoadModule ssl_module /usr/lib/apache/1.3/mod_ssl.so

<IfModule mod_proxy.c>
<IfModule mod_ssl.c>
Listen 80
Listen 443

<VirtualHost 123.123.123.123:443> 
DocumentRoot "/var/www/sslproxy"
ServerName ssl.xyz.pureserver.info
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/apache/ssl.crt/server.crt
SSLCertificateKeyFile /etc/apache/ssl.key/server.key
SSLEngine on

Include /etc/apache/ssldomains
</VirtualHost>

Die ssldomains:

Code: Select all

#CONFIXX
RedirectPermanent /  https://ssl.xyz.pureserver.info/
ProxyPass         /  http://confixx.xyz.pureserver.info/
ProxyPassReverse  /  http://confixx.xyz.pureserver.info/

#PHPMyAdmin
RedirectPermanent /phpmyadmin  https://ssl.xyz.pureserver.info/phpmyadmin/
ProxyPass         /phpmyadmin/ http://www.xyz.pureserver.info/phpmyadmin/
ProxyPassReverse  /phpmyadmin/ http://www.xyz.pureserver.info/phpmyadmin/

[majortermi]

Mir persönlich geht es nur um Verschlüsselung, nicht um gültige Zertifikate.

Du hast anscheinend nicht wirklich verstanden, wie assymmetrische Verschlüsselung funktioniert, oder überprüfst du bei jeder Verbindung manuell den Fingerprint?

[bernostern]

Du hast anscheinend nicht wirklich verstanden, wie assymmetrische Verschlüsselung funktioniert, oder überprüfst du bei jeder Verbindung manuell den Fingerprint?

Da könntest du recht haben. Ich will nur nicht, dass Passwörter unverschlüsselt übertragen werden. Das erreiche ich doch auch ohne ein sign. Cert. oder?

Gruß,
Bern

[majortermi]

Da könntest du recht haben. Ich will nur nicht, dass Passwörter unverschlüsselt übertragen werden. Das erreiche ich doch auch ohne ein sign. Cert. oder?

Nein, weil das keine Man-In-The-Middle-Attack ausschließt (außer du überprüfst eben selbst den Fingerprint).

Wenn das Zertifikat nicht von einer dem Browser bekannten CA signiert wurde, kann der Browser nicht überprüfen, ob es sich um ein gefälschtes oder ein echtes Zertifikat handelt.

Beispiel: Ich kann einfach ein Zertifikat für die Domain "microsoft.com" erstellen und einen Server einrichten, der dieses verwendet. Das es sich um ein gefälschtes Zertifikat handelt, ist nur daran erkennbar, dass es nicht von einer CA signiert wurde (die das natürlich nicht macht, weil ich ja nicht der Eigner von "microsoft.com" bin).

Jetzt sorge ich dafür, dass du auf meinem Server landest, wenn du auf "microsoft.com" gehst (z.B. über DNS-Spoofing). Da du die Warnung im Browser beim Verbindungsaufbau ignorierst, hast du eine sicher verschlüsselte Verbindung aufgebaut, nur eben nicht zu dem Server den du glaubst. Ich kann jetzt alle Daten, die du mir schickst entschlüsseln, mitlesen und dann an den echten "microsoft.com"-Server weiterleiten (mit der Antwort ist es das gleiche in der umgekehrten Richtung), ohne, dass du davon etwas merkst. Ich kann natürlich die Daten die du schickst, oder empfängst beliebig modifizieren, wie z.B. eine Datei, die du herunterladen willst, durch eine mit einem Trojaner versehene Version ersetzen, etc.

Um es also klar zu sagen: Zertifikate, die nicht von einer CA signiert wurden, sind (fast) wertlos und nur für Testzwecke zu gebrauchen.

Bei Anwendungen, die nur von einer begrenzten Rechnergruppe verwendet werden, kann man durchaus eine eigene CA verwenden. Dann muss man allerdings dafür Sorge tragen, dass das CA-Zertifikat auf all diesen Rechnern auf einem sicheren Weg (z.B. indem man persönlich mit einer Diskette vorbeigeht) installiert wird.

Diese Situation unterscheidet sich dann faktisch nicht mehr von einer öffentlichen CA, da die öffentlichen CAs eben nur den Vorteil haben, dass ihre Zertifikate in so gut wie allen Browsern bereits vorinstalliert sind.

[bernostern]

Ok, danke für deine Antwort! Ich glaub ich versteh jetzt wo das Problem liegt.
Man sollte also , um eine wirklich verschlüsselte und glaubwürdige Verbindung zu haben, ein Cert kaufen und gscheit signieren lassen.
Der SSL-Proxy hilft also nur dabei mit einem Cert mehrere Domains verschlüsseln zu können. Aber diesen SSL-Proxy kann man sich aber sparen, wenn man den Parameter in der openssl.cnf den subjectAltName-Parameter setzt.

Kann man, wenn man ein echtes Cert gekauft hat, dieses beliebig oft neu erstellen und dann wieder erneut (kostenlos!) signieren lassen, oder ist diese Signierung einmalig von der CA?


Schönen Gruß,
Bern

[majortermi]

Kann man, wenn man ein echtes Cert gekauft hat, dieses beliebig oft neu erstellen und dann wieder erneut (kostenlos!) signieren lassen, oder ist diese Signierung einmalig von der CA?

Ein Zertifikat gilt immer nur für einen bestimmten Zeitraum und wird auch nur für diese Gültigkeitsdauer von der CA signiert. Der Zeitraum liegt dabei üblicherweise zwischen einem und fünf Jahren.
Die "Verlängerung" (also die Signierung eines neuen Zertifikats für die gleiche Domain), wird dir von der CA erneut in Rechnung gestellt, allerdings gibt es für "Bestandskunden" oft etwas günstigere Preise.

[andreask2]

Hallo!

Code: Select all

subjectAltName = DNS:http://www.domain1.com,DNS:*.domain2.com

Kennt jemand diesen Parameter und verwendet ihn, oder kann mir jemand abraten ihn zu benutzen?

Die Sache hat mehrere Haken. Ich muss zugeben dass ich mit der openssl.cnf nicht auskenne, aber es gibt noch andere Probleme:

Problem 1:
Du kannst bei SSL AFAIK keine namebased Virtual Hosts im Apachen verwenden, nur IP-Based, oder eben verschiedene Ports.
Das liegt an der Natur von SSL: SSL liegt zwischen HTTP und TCP-Protokoll. Normalerweise wird ein Zertifikat auf genau einen Hostnamen mit genau einer IP-Adresse ausgestellt.
Wenn Du jetzt mehrere per SSL verschlüsselte Hostnamen unter einer IP betreiben wolltest, bräuchtest Du für jeden Hostnamen ein eigenes Zertifikat, das heißt, der Server muss den zu verwendenen Schlüssel schon kennen, bevor er an die HTTP-Header kommt. Nur leider steht der Hostname - der für namebased virtual-hosts nötig ist, nur im HTTP-Header, das heißt der Server weiß nicht, welches Zertifikat er verwenden soll. Aus diesem Grunde funktionieren mit SSL nur IP-based Virtual hosts, da die IP-Adresse im Gegensatz zum Hostname schon unter der SSL-Ebene bekannt ist.

Problem 2:
1und1 bietet AFAIK keine zusätzlichen IPs an.

Problem 3:
Normalerweise werden SSL-Zertifikate nur für eine Hostname->IP Zuordnung vergeben. Wildcard-Zertifikate (*.domain.tld) sind erheblich teurer.


Grüße
Andreas