abfrage php - ssl oder nicht...

[arkos]

moin zusammen,

wollt nur mal ne meinung von euch hören...

ich musste gerade auf einem ziemlich eingeschränkten webpaket eine prüfung einbauen, ob die seite via ssl aufgerufen wird oder nicht. problem dabei ist, dass sich das webpaket eines ssl-proxys bedient und keine "wirkliche" eigene ssl-verbindung (geschweige zertifikat) hat.

mit $_SERVER["SSL_PROTOCOL"] etc wird man dabei nichts.

ich habe es mit getallheaders() gelöst, und die rückgabe auf ssl überprüft. wenn kein ssl vorhanden ist, header location auf die ssl verbindung.

denkt ihr, dass ist ok...?

[jahlives]

Und wenn du den Serverport prüfst? Müsste doch immer 443 für HTTPS sein

Gruss

tobi

[onemorenerd]

$_SERVER['HTTPS']?

[arkos]

Original geschrieben von onemorenerd
$_SERVER['HTTPS']?

spuckt genau so wenig aus wie $_SERVER["SSL_PROTOCOL"]

kurz: nüschts

ich probiers noch mal mitm port - sobald ich rausgefunden habe wie

danke schonma, aber was spricht gegen die header-abfrage?


edit:
so, ausgepuckt wird durch diese weiterleitung über den proxy tatsächlich:

[SERVER_PROTOCOL] => HTTP/1.1
[SERVER_PORT] => 80

ich komme da scheibar echt nur zuverlässlich über die einträge:
[HTTP_VIA] => ssl.proxy.blablabla
[HTTP_X_FORWARDED_HOST] => ssl.proxy.blablabla
[HTTP_X_FORWARDED_SERVER] => ssl.proxy.blablabla

ran.
habe den via mit getallheaders abgefragt... denkt ihr, das is ok?

[onemorenerd]

Mehr wird nicht drin sein, wenn die Verbindung zwischen dem Proxy und deinem Host nicht über SSL läuft.

[arkos]

danke dir. das wollte ich noch mal bestätigt haben. siehst du ein sicherheitsrisiko darin, dass zw. proxy und host keine ssl leitung steht? die server stehen physikalisch in ein und demselben rechenzentrum - heißt in direkter verbindung...

guten morgen

[onemorenerd]

Natürlich ist das Risiko höher. Jede Komponente in einem System ist eine Angriffsfläche. Der Proxy selbst sowie die Hops zwischen Proxy und deinem Server sind in deinem Fall zusätzliche Komponenten. Wenn der unverschlüsselte Traffic das RZ nicht verläßt und der Proxy in fähigen Händen ist, brauchst du dir aber keine Sorgen zu machen. Die meisten SSL-Attacken sind sowieso man-in-the-middle-Varianten, die auf Schwachstellen in der Zertifikatsverarbeitung beim Client ausnutzen.

Andere Frage: Wieso brauchst du den Proxy eigentlich? Was spricht gegen ein selbstsigniertes Zertifikat?

[arkos]

danke dir.

es handelt sich dabei um ein webpack - also geshared ohne eigene ip. deswegen ist bei diesem leistungspaket ein eigenes zertifikat nicht möglich. das nächst höhere webpack, was das könnte ist demjenigen, den ich gerade den "ssl-gefallen" getan habe zu teuer. ergo war/ist nur die lösung über den proxy möglich.