[FREEBSD] Vhosts +SSL +apache op virtual ip adressen

[Verwijderd]

Op moment draai ik een 24/7 server met FreeBSD 5.3 Release.

Deze server host op moment 3 domein namen met meerder vhosts erop.
Gebruikte software zijn Apache 2.0.52 + PHP5 + MYSQL . Nou wil ik graag meerdere vhost hebben met SSL voornamelijk voor webmail.

Echter dit zou niet mogelijk zijn omdat ik slechts 1 Ip heb voor naar buiten.

Via google kom ik maar niet aan een passende oplossing.

Extra info de server is verbonden aan het internet via een hardware matige router/firewall .

Heeft iemand een oplossing voor dit probleem. Op moment werk ik me laatste idee uit maar betwijfel of dit gaat werken.

De nic instellen met virtueele ip's en deze in de host config vermelden met de bijhorende domein namen. En dan die als vhost gaan gebruiken met ssl.

Ik hoop dat iemand me verder kan helpen.

[Hans]

name based virtual hosts zijn niet mogelijk met SSL. Dat moet op indiv. IPs

[Verwijderd]

mJa oka maar als je virtueel ip gebruikt dan bv 192.168.1.102 en 192.168.1.103 voor je ip based ssl host ?

[moto-moi]

Dan kan het wel.
Maar namebased is het onmogelijk omdat ssl op een lagere osi laag wordt geinitieerd.
Op IP is het uiteraard wel mogelijk, maar dat is vrij simpel zelf uit te zoeken volgens mij

[Verwijderd]

moto-moi schreef op zondag 05 december 2004 @ 19:04:
Dan kan het wel.
Maar namebased is het onmogelijk omdat ssl op een lagere osi laag wordt geinitieerd.
Op IP is het uiteraard wel mogelijk, maar dat is vrij simpel zelf uit te zoeken volgens mij

Dat van ip alleen wist ik wel alleen of het gaat werken bij gebruik van virtueele ip's en maar 1 echte ip is eigenlijk de vraag. Maar ik zal nog eens wat aan gaan rommelen

[Sendy]

Dat gaat niet werken. Als je denkt van wel, hoe zou je apache hosts zonder SSL op verschillende "virtuele" (WTF?) ip's hosten? Dat kan toch ook niet?

De enige mogelijkheiden voor verschillende SSL hosts zijn:
1) Meer ipnummers
2) Verschillende porten

2) is natuurlijk niet zo netjes, maar wel mogelijk

[PowerSp00n]

Virtual Hosts zijn nog wel mogelijk, maar verschillende certificates voor die vhosts te gaan gebruiken gaat je niet lukken . Beetje afhankelijk van wie er van die webmail gebruik gaat maken of je met meerdere IP's gaat werken of gewoon de domain mismatch weg klikt.

[ Voor 3% gewijzigd door PowerSp00n op 06-12-2004 15:58 ]

[Verwijderd]

hm mja ik zit gewoon vast aan 1 ip dus dan zal het werken via verschillende poorten worden. Is dan helaas niks anders aan te doen.

[Verwijderd]

/me zit ff random te denken....

Is het niet mogelijk om een apache server met meerdere vhosts op localhost te draaien, om vervolgens een apache reverse proxy met ssl support hiervoor te plakken. Hierdoor heb je 1 hosts (ip) met ssl support met meerdere vhosts erachter. Ok, je url's komen er dan wel zoiets uit te zien, maar het is mogelijk:

code:

https://www.example.com/vhost1
https://www.example.com/vhost2
https://www.example.com/vhost2
...
https://www.example.com/vhostN

Zoiets dus (pardon my ascii):

code:

       [internet]
           |
    [https rev. proxy]         (extern ip)
    /  |     |       \
[vh1] [vh2] [vh3] ... [vhN]    (localhost)

[ Voor 29% gewijzigd door Verwijderd op 07-12-2004 11:15 ]

[blender]

Volgens mij kan het niet 'netjes'. Alle verkeer dat op poort 443 aan de buitenkant binnenkomt kun je maar naar 1 IP door routeren. Dat is dus het enige IP adres waarop je SSL kunt draaien. Je kunt voor zover ik weet wel unlimited non-SSL virtual hosts naast die ene SSL virtual host draaien.

Als je meerdere SSL hosts op 1 machine wilt zul je die allemaal op aparte poortnummers moeten laten luisteren zodat ze makkelijk doorgerouteerd kunnen worden van buitenaf.

Op de webmachine zelf geef je je netwerkkaart gewoon wat aliasen en laat je apache gewoon luisteren op poortje 443, alleen aan de buitenkant zul je voor elke alias aan de binnenkant een aparte rule moeten maken.

[Olaf van der Spek]

Dat SSL/TLS niet kan met name-based virtual hosts is wel erg jammer. Ik vraag me af wanneer ze dat toevoegen aan SSL/TLS.

[Sendy]

Olaf >
Het is gewoon niet mogelijk. Zie de volgende deadlock:
1) Apache krijgt een request op port 443 voor een SSL host.
2) Apache moet de host erbij zoeken om het geschikte certificaat te vinden (anders krijg je host-mismatches)
3) Apache kan het request niet lezen (want SSL), dus het certificaat niet vinden.
4) DEADLOCK

[Olaf van der Spek]

Sendy schreef op dinsdag 07 december 2004 @ 23:33:
Olaf >
Het is gewoon niet mogelijk. Zie de volgende deadlock:

Dus moet SSL aangepast worden zodat de vhost beschikbaar is voor de SSL handshake.
Of wachten op IPv6.

Blijkbaar wordt er (al) aan gewerkt: http://www.ietf.org/rfc/rfc2817.txt en http://www.ietf.org/rfc/rfc3546.txt

[ Voor 19% gewijzigd door Olaf van der Spek op 08-12-2004 01:52 ]

[CyBeR]

OlafvdSpek schreef op woensdag 08 december 2004 @ 00:35:
[...]

Dus moet SSL aangepast worden zodat de vhost beschikbaar is voor de SSL handshake.

Mja. Dat kan dus niet. En wel om twee redenen:

1) Dan werken de reeds bestaande implementaties niet meer
2) Dan versturen we dus ongecodeerde data terwijl het punt van SSL nu juist is dat dat niet gebeurt.

IPv6 lost dat niet op. (Wel heb je dan makkelijker meerdere IP-adressen, maar dat heeft niets met SSL te maken).

[Olaf van der Spek]

CyBeR schreef op woensdag 08 december 2004 @ 02:32:
Mja. Dat kan dus niet. En wel om twee redenen:

1) Dan werken de reeds bestaande implementaties niet meer

Het is vast wel in een backwards compatible jasje te gieten.

2) Dan versturen we dus ongecodeerde data terwijl het punt van SSL nu juist is dat dat niet gebeurt.

Wat is het probleem van het ongecodeerd versturen van de hostname?

IPv6 lost dat niet op. (Wel heb je dan makkelijker meerdere IP-adressen, maar dat heeft niets met SSL te maken).

Dat heeft in die zin met SSL te maken dat je weer makkelijk IP based vhosts kunt draaien.

[Verwijderd]

OlafvdSpek schreef op woensdag 08 december 2004 @ 10:19:
[...]
Wat is het probleem van het ongecodeerd versturen van de hostname?
[...]

Nouja, 1 van de eigenschappen van ssl is dat het hostname spoofing voorkomt.

[Olaf van der Spek]

Ja, maar dat vereist (IMO) niet dat de hostname alleen versleuteld wordt verstuurd.

[Verwijderd]

tuurlijk moet er meer gebeuren, maar dat is niet echt aan de orde. Als je een niet-geldige fqdn in je ssl certificaat hebt staan, haal je 1 van de eigenschappen van ssl weg, namelijk de bescherming tegen man-in-the-middle attacks.

Overigens, had je nog wat aan die oplossing met een reverse-proxy?

[CyBeR]

OlafvdSpek schreef op woensdag 08 december 2004 @ 10:19:
[...]

Wat is het probleem van het ongecodeerd versturen van de hostname?

Omdat je dan niet kunt voorkomen dat een spoofer weet welke hostname je opzoekt. Hij kan dan dus z'n certificaten aanpassen en zo een passend certificaat maken.

Dat heeft in die zin met SSL te maken dat je weer makkelijk IP based vhosts kunt draaien.

En dat staat dus weer helemaal los van SSL.

Ik heb vaker met jou zo'n zinloze discussie gehad over dingen waar je niets van af blijkt te weten. Dus ik hou 't bij deze al voor gezien.

[ Voor 13% gewijzigd door CyBeR op 08-12-2004 13:52 ]

[knopper]

Olav heeft zeker gelijk, want je kunt dan uiteraard meer SSL vhosts draaien....

[Olaf van der Spek]

Verwijderd schreef op woensdag 08 december 2004 @ 13:48:
tuurlijk moet er meer gebeuren, maar dat is niet echt aan de orde. Als je een niet-geldige fqdn in je ssl certificaat hebt staan, haal je 1 van de eigenschappen van ssl weg, namelijk de bescherming tegen man-in-the-middle attacks.

Was dat een reactie op mijn bericht?
Ik zeg namelijk niet dat je een ongeldige fqdn in het certificaat moet zetten.

CyBeR schreef op woensdag 08 december 2004 @ 13:51:
Omdat je dan niet kunt voorkomen dat een spoofer weet welke hostname je opzoekt. Hij kan dan dus z'n certificaten aanpassen en zo een passend certificaat maken.

Aangezien je nu per IP adres maar een SSL vhost kan draaien en de spoofer nu het IP adres kan achterhalen, kan de spoofer ook nu de hostname achterhalen en certificaten aanpassen.
Welke attack jij daarmee echter denkt uit te voeren is mij een raadsel.

[CyBeR]

Zucht. Ok, nog een keer dan.

[b][message=22313965,noline]OlafvdSpek schreef op woensdag 08 december

Aangezien je nu per IP adres maar een SSL vhost kan draaien en de spoofer nu het IP adres kan achterhalen, kan de spoofer ook nu de hostname achterhalen en certificaten aanpassen.

Ja, want de reverse van een IP-adres is altijd hetzelfde als de naam van een SSL VirtualHost.

Welke attack jij daarmee echter denkt uit te voeren is mij een raadsel.

Man-in-the-middle.

[Olaf van der Spek]

CyBeR schreef op woensdag 08 december 2004 @ 22:09:
Ja, want de reverse van een IP-adres is altijd hetzelfde als de naam van een SSL VirtualHost.

Dus jij vertrouwt er (nu) op dat een attacker de naam van jouw SSL vhost niet kan achterhalen?

[Verwijderd]

Hm alleen de publieke certificaat kan die ophalen.

De private certificaat wordt nooit verstuurd. Wel zou kunnen dat je dan een eigen private key gaat gebruiken met daar bij behorende public key.

Echter dan krijgt de gebruiker neem ik aan wel een melding van de browser dat er een vreemde wisseling heeft plaats gevonden.

Zelfde wat eigenlijk zou gebeuren als je dat zou doen met ssh2 login. Als je ineens een bericht krijgt dat de keys gewijzigd zijn kan dat duiden op spoof attack.

Maar goed daar ging het niet helemaal om

Ik zit nu eenmaal vast aan 1 echte IP. Mijn provider wil er ook niet meer uit geven dus dat word creatief zijn met poorten en rewrite.

wil het zo gaan doen.

Gebruiker vraagt adres webmail.host.com aan. Mijn apache doet dan een rewrite of redirect (trouwens) naar bijvoorbeeld wmail.host.com:444

of het gaat werken weet ik zo uit hoofd niet heb ook nog geen kans gezien om dit te testen.

[Olaf van der Spek]

Verwijderd schreef op woensdag 08 december 2004 @ 22:53:
De private certificaat wordt nooit verstuurd. Wel zou kunnen dat je dan een eigen private key gaat gebruiken met daar bij behorende public key.

Echter dan krijgt de gebruiker neem ik aan wel een melding van de browser dat er een vreemde wisseling heeft plaats gevonden.

Inderdaad.

Gebruiker vraagt adres webmail.host.com aan. Mijn apache doet dan een rewrite of redirect (trouwens) naar bijvoorbeeld wmail.host.com:444

Een rewrite werkt waarschijnlijk niet, maar een redirect zou wel moeten werken.

[Sendy]

Verwijderd schreef op woensdag 08 december 2004 @ 22:53:
Hm alleen de publieke certificaat kan die ophalen.

De private certificaat wordt nooit verstuurd. Wel zou kunnen dat je dan een eigen private key gaat gebruiken met daar bij behorende public key.

Echter dan krijgt de gebruiker neem ik aan wel een melding van de browser dat er een vreemde wisseling heeft plaats gevonden.

Zelfde wat eigenlijk zou gebeuren als je dat zou doen met ssh2 login. Als je ineens een bericht krijgt dat de keys gewijzigd zijn kan dat duiden op spoof attack.

Maar goed daar ging het niet helemaal om

Ik zit nu eenmaal vast aan 1 echte IP. Mijn provider wil er ook niet meer uit geven dus dat word creatief zijn met poorten en rewrite.

wil het zo gaan doen.

Gebruiker vraagt adres webmail.host.com aan. Mijn apache doet dan een rewrite of redirect (trouwens) naar bijvoorbeeld wmail.host.com:444

of het gaat werken weet ik zo uit hoofd niet heb ook nog geen kans gezien om dit te testen.

Je bent vergeten erbij te zeggen wat allemaal SSL is en wat niet, maar ik kan goed raden.

De url http://webmail.virtualhost1.com wordt geredirect naar de url https://webmail.host.com:444. Een andere url, http://webmail.virtualhost2.com wordt geredirect naar https://webmail.host.com:445.

Dat lijkt me gewoon mogelijk. Maar professioneel, ehm, nee. Het ziet er niet uit

[Verwijderd]

Sendy schreef op woensdag 08 december 2004 @ 23:13:
[...]


Je bent vergeten erbij te zeggen wat allemaal SSL is en wat niet, maar ik kan goed raden.

De url http://webmail.virtualhost1.com wordt geredirect naar de url https://webmail.host.com:444. Een andere url, http://webmail.virtualhost2.com wordt geredirect naar https://webmail.host.com:445.

Dat lijkt me gewoon mogelijk. Maar professioneel, ehm, nee. Het ziet er niet uit

Bedoelde het iets anders namelijk

http://webmail-vhost1.host.com -> https://mail-vhost1.host1.com
http://webmail-vhost2.host.com -> https://mail-vhost2.host2.com:444
http://webmail-vhost3.host.com -> https://mail-vhost3.host3.com:445

Dit zou gewoon moeten kunnen. Omdat de dns naam niet van belang is het gaat bij SSL puur om het IP adres.

Normaal kun je dus 1 SSL host hebben op 1 ip adres. Echter door gebruik te maken van andere poorten dan de standaard port 443 kun je dit wel weer.

Dus mijn aangeven methode zoals hierboven geschreven zou moeten werken.

Rest alleen de vraag nog of ik dit kan doen met 1 instantie van apache of dat ik er 2 moet opstarten. Dit in verband met het opzoeken van de hostnamen. Dit kan tot problemen lijden met SSL

1 Met dan alleen de normale vhosts op poort 80 en 1 Instantie met alleen de SSL hosts. Dan vermijd ik het probleem dat apache eerst een hostname er bij gaat zoeken maar meteen weet dat het om een SSL verbinding gaat.

Maar goed dat kan ik snel en relatief gemakkelijk uit proberen.

Nee echt profi is anders. maar dan had ik ook wel meer ip's .

Maar het is wel een oplossing die werkt. En het gaat gelukkig maar om 3 domeinen

Dus 1 kan gewoon op 443 en de andere inderdaad op 444 en 445. Overigens de meeste mensen zullen dat niet eens door hebben.
De meeste gebruikers tikken een url in. En verder zullen ze ook niet snel kijken.

Geeft natuurlijk niet aan dat wanneer je profi(met betalende klanten) aan de slag zou gaan met SSL en Apache dat je zo te werk zou moeten gaan.
Het zelf signen van die certificates is dan ook uit de boze .

Dat is trouwens nog aan de prijzige kant om te doen. Waarbij ik wed dat nog geen 1% van de gebruikers het zal checken. Maar goed scheelt de gebruiker wel weer een melding van de browser

Via IPV6 zou nog wel willen maar dan moet ik nog even wachten dan kan ik daar beschikking over hebben en dan kan ik maar liefst 65.000 duizend ip's krijgen

[ Voor 50% gewijzigd door Verwijderd op 09-12-2004 01:27 ]