[PHP] Hoe HTTP vs HTTPS detecteren?*

[Stefan|IA2]

Nou mensen de titel zegt het al voor een groot gedeelte, hoe kan je controleren of de verbinding via http of via https is met behulp van PHP

Ik heb al gegoogled op dit item alleen de stukjes code die ik vind werken niet (meer). Zoals:

code:

if($_SERVER['HTTPS'])
    echo 'secured';

Heeft iemand hier een suggestie en/of oplossing voor?

Alvast bedankt!

PS. Mag dit topic verschoven worden van WEB -> PRG...

[ Voor 9% gewijzigd door Stefan|IA2 op 15-09-2009 17:37 ]

[Bosmonster]

http://nl2.php.net/manual/en/reserved.variables.server.php

Daar zou je het toch gewoon uit moeten kunnen halen?

[Verwijderd]

Bekijk eens heel de $_SERVER array. Je kunt eventueel nog op poortnummer selecteren. Ook dat staat in die array.

[Stefan|IA2]

@Bosmonster, dat dacht ik dus ook maar blijkbaar moet dat ingeschakeld zijn ergens alleen dat heeft mijn webhosting niet gedaan

@Cheatah, ik heb ook getest met de poortnummers, maar dan hebben we weer een probleem want beide verbindingen gebruiken poort 80

[BtM909]

PS. Mag dit topic verschoven worden van WEB -> PRG...

Maak daar voortaan een TR voor aan, dat valt sneller op
/Schopje naar de buren

[Dutchmega]

In de meestal gevallen zal de poort 443 zijn bij SSL. Combineer dit met SERVER_PORT en je komt al ver

[Stefan|IA2]

@Dutchmega, zoals ik al in mijn vorige post zei:

ik heb ook getest met de poortnummers, maar dan hebben we weer een probleem want beide verbindingen gebruiken poort 80

[CyBeR]

Stefan Keijzer schreef op dinsdag 15 september 2009 @ 18:22:
@Dutchmega, zoals ik al in mijn vorige post zei:

[...]

Dan heb je een ander probleem om op te lossen. HTTPS hoort niet op poort 80 maar op poort 443. Als je dat anders doet heb je muchos gezeik met firewalls. (Tenzij je iets maakt wat alleen in-house is natuurlijk.)

[Stefan|IA2]

Dan heb je een ander probleem om op te lossen. HTTPS hoort niet op poort 80 maar op poort 443.

Jah daar ben ik zojuist ook achter gekomen, maar ik kan daar niets aan veranderen aangezien mijn webhost dat zelf zo ingesteld heeft staan. Wijzigen doen ze niet omdat ze het blijkbaar altijd op deze manier doen.

[Verwijderd]

Bij mijn PHP installatie is het $_SERVER['HTTPS'] == 'on', je moet alleen wel even controleren of HTTPS is geset (isset) anders geeft hij een foutmelding als je geen beveiligde verbinding hebt.

Dus mijn vraag ? wat ging er fout ?

[Stefan|IA2]

code:

echo (isset($_SERVER['HTTPS']) && ($_SERVER['HTTPS'] == 'ON')) ? 'secured' : 'not secured';

Bij beide (bij de http en de https verbinding) krijg ik not secured terug...

[ Voor 10% gewijzigd door Stefan|IA2 op 15-09-2009 18:37 ]

[pedorus]

Je moet ON ook niet met hoofdletters schrijven. Kijk anders eens naar de output van phpinfo().

[Verwijderd]

Ik heb een php bestandje gemaakt met phpinfo(); er in waar je een mooi overzicht mee krijgt. Test het op HTTP en HTTPS uit en zie wat het verschil is.

[edit] Ow sorry, die ON was een tikfoutje van mij. Slimste is om altijd de case aan te passen dus 'on' == strtolower($_SERVER['HTTPS']).

[ Voor 31% gewijzigd door Verwijderd op 15-09-2009 18:45 ]

[eghie]

PHP:

echo ((!empty($_SERVER["HTTPS"]) && strtolower($_SERVER["HTTPS"]) == "on")) ? 'http' : 'https';

[Stefan|IA2]

@Pedorus & Blackspot, de on met hoofdletters en kleine letters maakt op een andere server (die wel https is en het ook accepteerd) niet uit. Maar dat maakt nu niet uit het gaat om die ander en die reageert er ook niet op als je het met kleine of hoofdletter doet, nogsteeds beide not secured.

Waar zou ik verschil moeten zien in de info.php? Als ik ze beide vergelijk dan maakt dat vrij weinig uit, misschien heb je iets specifics (hoe schrijf je dat ) waar ik verschil zou moeten zien?

[Turiya]

Ik zou de configuratie er nog eens goed op nakijken, want volgens mij is het technisch onmogelijk om http en https op dezelfde poort (en dezelfde hostname) te gebruiken.

[skabouter]

van php.net

'HTTPS'
Set to a non-empty value if the script was queried through the HTTPS protocol.

Note: Note that when using ISAPI with IIS, the value will be off if the request was not made through the HTTPS protocol.

dus

eghie schreef op dinsdag 15 september 2009 @ 18:48:

PHP:

... && strtolower($_SERVER["HTTPS"]) == "on")...

is wel wat overbodig, er staat namelijk nergens dat de waarde van $_SERVER['HTTPS'] niet 1 of true kan zijn bijvoorbeeld. Beter voor de comptabiliteit zou dus zijn:

PHP:

$protocol = !empty($_SERVER['HTTPS']) ? 'https://' : 'http://';

p.s. let ook op de note, als je hoster gebruikt maakt van IIS dan moet je het anders testen.

[ Voor 4% gewijzigd door skabouter op 15-09-2009 19:03 ]

[Stefan|IA2]

Turiya schreef op dinsdag 15 september 2009 @ 19:00:
Ik zou de configuratie er nog eens goed op nakijken

Dat kan ik dus niet doen, dat moet de webhosting zelf doen...

[Janoz]

Ik heb een donkerbruin maar zeer sterk vermoeden dat je host helemaal geen https ondersteund. Een webserver kanwil je geen http en https op 1 poort laten draaien.

[ Voor 5% gewijzigd door Janoz op 15-09-2009 19:29 ]

[BCC]

Nou, met IIS kan dat dus wel, maar ik zou niet weten waarom je dat zou willen.

[Stefan|IA2]

@Janoz, de webhost geeft zelf aan dat ze SSL ondersteunen. Nog even ter informatie ze draaien op de servers Linux.

[pedorus]

Stefan Keijzer schreef op dinsdag 15 september 2009 @ 18:52:
@Pedorus & Blackspot, de on met hoofdletters en kleine letters maakt op een andere server (die wel https is en het ook accepteerd) niet uit. Maar dat maakt nu niet uit het gaat om die ander en die reageert er ook niet op als je het met kleine of hoofdletter doet, nogsteeds beide not secured.

Waar zou ik verschil moeten zien in de info.php? Als ik ze beide vergelijk dan maakt dat vrij weinig uit, misschien heb je iets specifics (hoe schrijf je dat ) waar ik verschil zou moeten zien?

Het lijkt me wat lastig als wij moeten gaan gokken hoe je phpinfo()-output eruit ziet. Kijk gewoon naar HTTPS en _SERVER["SERVER_PORT"] nadat je een https-verbinding maakt, of laat ons die output zien. De code van eghie works for me (wel omgekeerd resultaat).

skabouter schreef op dinsdag 15 september 2009 @ 19:03:
p.s. let ook op de note, als je hoster gebruikt maakt van IIS dan moet je het anders testen.

Vandaar dat testen op 'on' helemaal zo gek nog niet is. Straks retourneert een andere webserver 'niet aan', en dan kun je maar beter van een onveilige connectie uitgaan.

BCC schreef op dinsdag 15 september 2009 @ 19:19:
Nou, met IIS kan dat dus wel, maar ik zou niet weten waarom je dat zou willen.

Lijkt me gek. Heb je een linkje?

[skabouter]

pedorus schreef op dinsdag 15 september 2009 @ 19:38:
[...]

Vandaar dat testen op 'on' helemaal zo gek nog niet is. Straks retourneert een andere webserver 'niet aan', en dan kun je maar beter van een onveilige connectie uitgaan.

[...]

Voor productie heb je 101% gelijk, maar om te testen is het overbodig, als de server (per ongelijk) iets anders dan on geïnterneerd dan lijkt het ook dat er geen https verbinding is.

[Orion84]

Stefan Keijzer schreef op dinsdag 15 september 2009 @ 19:21:
@Janoz, de webhost geeft zelf aan dat ze SSL ondersteunen. Nog even ter informatie ze draaien op de servers Linux.

Als https daadwerkelijk ondersteund wordt, dan moet je dat toch snel genoeg merken in je browser, als je het eens probeert met een loze testpagina?

Als HTTPS gewoon werkt in je browser zonder dat je zelf opgeeft dat ie op poort 80 moet verbinden, dan draait HTTPS dus gewoon onder poort 443. Als HTTPS niet werkt zonder een poort op te geven, maar wel werkt als je :80 achter de domeinnaam zet, dan draait er inderdaad een HTTPS server op poort 80. Als HTTPS niet werkt zonder poort toevoeging en ook niet zonder, dan draait er überhaupt geen HTTPS.

[ Voor 31% gewijzigd door Orion84 op 15-09-2009 20:18 ]

[Remus]

Stefan Keijzer schreef op dinsdag 15 september 2009 @ 19:21:
@Janoz, de webhost geeft zelf aan dat ze SSL ondersteunen. Nog even ter informatie ze draaien op de servers Linux.

Lijkt me sterk dat ze SSL draaien op port 80. De manier waarop de SSL-handshake werkt maakt het niet mogelijk om zowel HTTP als HTTPS op één poort te ondersteunen (al zijn er wel oplossingen waarbij een HTTP connect naar poort 80 geredirect wordt naar HTTPS op poort 443).

[r0b]

Orion84 schreef op dinsdag 15 september 2009 @ 20:08:
[...]

Als https daadwerkelijk ondersteund wordt, dan moet je dat toch snel genoeg merken in je browser, als je het eens probeert met een loze testpagina?

Als HTTPS gewoon werkt in je browser zonder dat je zelf opgeeft dat ie op poort 80 moet verbinden, dan draait HTTPS dus gewoon onder poort 443. Als HTTPS niet werkt zonder een poort op te geven, maar wel werkt als je :80 achter de domeinnaam zet, dan draait er inderdaad een HTTPS server op poort 80. Als HTTPS niet werkt zonder poort toevoeging en ook niet zonder, dan draait er überhaupt geen HTTPS.

Inderdaad, ik vermoed dat dat inderdaad de verwarring oproept.

https://blahblah = 443
http://blahblah = 80
https://blahblah:80 = 80
http://blahblah:443 = 443

[IStealYourGun]

Eigenlijk snap ik niet waarom je dit met PHP wil oplossen. Het is toch veel makkelijker en secure als je de https verbinding onderbrengt in een aparte virtual host. De ene luister op poort 80 en de andere op 443.

* IStealYourGun vermoed dat dat we hier te maken hebben met een server die ergens in een huiskamer staat met self-signed certificaten.

[Erkens]

IStealYourGun schreef op dinsdag 15 september 2009 @ 23:00:
Eigenlijk snap ik niet waarom je dit met PHP wil oplossen. Het is toch veel makkelijker en secure als je de https verbinding onderbrengt in een aparte virtual host. De ene luister op poort 80 en de andere op 443.

Waarom meer configwerk en meer code gebruiken als je alleen de SSL verbinding gebruikt om bijvoorbeeld in te loggen? Of een bestelling te plaatsen op je site? Even een aparte vhost hiervoor gebruiken is gewoon onhandig in de meeste gevallen.
Normaal gesproken is het controleren van die $_SERVER['HTTPS'] voldoende, maar ik gok dat in dit geval er gewoon geen secure verbinding is opgezet (wellicht een auto redirect van https naar http? )

[Stefan|IA2]

hallo iedereen, inmiddels ben ik er achter wat het probleem is. De webhosting ondersteund https (SSL). Standaard wordt er voor iedereen op die webhosting (180000 klanten) een shared SSL aangeschaft. Echter wordt deze beveiligde verbinding op gezet via poort 80 op de server, want volgens hen is het een proxie waar de orginele http naar https wordt omgezet.Om een eigen https verbinding die niet via proxy loopt zal er een SSL moeten worden aangevraagt. Dat ga ik doen en dan horen jullie hoe dit afloopt.

[MueR]

Whuh? Ze zetten een HTTP protocol om naar HTTPS? Kan dat uberhaupt?

Ik zou een hoster zoeken die weet wat hij doet en een fatsoenlijke dienstverlening biedt.

[Erkens]

MueR schreef op woensdag 16 september 2009 @ 09:49:
Whuh? Ze zetten een HTTP protocol om naar HTTPS? Kan dat uberhaupt?

Ik zou een hoster zoeken die weet wat hij doet en een fatsoenlijke dienstverlening biedt.

Wat ik denk is dat ze dat HTTPS verkeer door sturen naar de HTTP service (proxy), niet echt een handige/veilige manier in ieder geval. Dus inderdaad zou ik ook op zoek gaan naar een andere partij.

[B-Man]

Op zich is het niet gek dat ze ssl-offloading proxy gebruiken, er zijn situaties waarin dat wenselijk is.
Heeft niets te maken met handig/veilig maar alles met scaling. De (reverse) proxy server en webserver hangen toch in hetzelfde netwerk, dus mits er een firewall voorzit is er niets aan de hand.

[Erkens]

B-Man schreef op woensdag 16 september 2009 @ 10:31:
Op zich is het niet gek dat ze ssl-offloading proxy gebruiken, er zijn situaties waarin dat wenselijk is.
Heeft niets te maken met handig/veilig maar alles met scaling. De (reverse) proxy server en webserver hangen toch in hetzelfde netwerk, dus mits er een firewall voorzit is er niets aan de hand.

Natuurlijk wel, je applicatie kan niet controleren dat er een secure verbinding is, daarnaast neem ik aan dat dit shared hosting is waarbij alsnog het locale netwerk imo niet te vertrouwen is.

[BCC]

offtopic:
[quote]pedorus schreef op dinsdag 15 september 2009 @ 19:38:
Lijkt me gek. Heb je een linkje?
[/quote]

Dit was het enige wat ik zo snel kon vinden via google, maar windows ondersteund(e) meerdere servers op de zelfde poort.
http://www.mail-archive.c....apache.org/msg05662.html

Helaas ben ik het ooit "werkend" tegengekomen

[ Voor 203% gewijzigd door BCC op 16-09-2009 14:36 ]

[B-Man]

Erkens schreef op woensdag 16 september 2009 @ 10:38:
[...]

Natuurlijk wel, je applicatie kan niet controleren dat er een secure verbinding is, daarnaast neem ik aan dat dit shared hosting is waarbij alsnog het locale netwerk imo niet te vertrouwen is.

De reverse proxy kan extra headers instellen zodra de verbinding beveiligd is (en ze weghalen indien dat niet het geval is). De backend server kan op die manier prima zien of de oorspronkelijke verbinding over SSL verloopt.

Als je het lokale netwerk niet vertrouwt, dan zit je sowieso verkeerd met shared hosting. De server zelf kan immers ook niet te vertrouwen zijn, laat staan de webserver.

Kort gezegd zou ik zelf sowieso nooit gevoelige data onderbrengen in een shared hosting omgeving; Helemaal als je ziet dat servers geen drol meer kosten.

[Gomez12]

B-Man schreef op woensdag 16 september 2009 @ 23:40:
[...]

De reverse proxy kan extra headers instellen zodra de verbinding beveiligd is (en ze weghalen indien dat niet het geval is). De backend server kan op die manier prima zien of de oorspronkelijke verbinding over SSL verloopt.

kan, kan, kan...
Misschien ook wel handig als dit ergens beschreven staat of verteld wordt zodat de klant er ook gebruik van kan maken...

Zoals ik het nu lees heeft de helpdesk hier niets over extra headers verteld etc. Zonder info en met een niet standaard config kan de klant hier dus moeilijk gebruik van maken...

[curry684]

Stefan Keijzer schreef op woensdag 16 september 2009 @ 08:22:
Dat ga ik doen en dan horen jullie hoe dit afloopt.

Volgens mij is het minder moeite om over te stappen naar een hoster met gezond verstand.

Van de 180000 klanten werd ik overigens wel benieuwd, en een tochtje langs Google doet mij vermoeden dat je het dan over LCN of BlueHost hebt, waarvan alleen de 2e claimt SSL te leveren op alle hostingpakketten. Indien het BlueHost betreft, had je bij $6.95/mnd voor deze waslijst aan features niet ook ergens zoiets van 'goh dat kan eigenlijk helemaal niet'?

[Cartman!]

Ze ondersteunen zelfs Flash bij Bluehost

[Gomez12]

Cartman! schreef op donderdag 17 september 2009 @ 00:19:
Ze ondersteunen zelfs Flash bij Bluehost

Ach Javascript is natuurlijk ook niet verkeerd als je hoster dat ondersteunt.

Het enige vreemde ik dat ze blijkbaar geen html ondersteunen...

Btw wat zijn : Courtesy Site Backups?
Moet ik me daarbij voorstellen dat als iemand zin heeft dat er dan een site backup gemaakt wordt ofzo? Ik snap het woordje courtesy hierin niet helemaal...

[Reptile209]

Klinkt als: in principe backuppen we, maar het is niet onze schuld als je data verliest en onze backup het niet doet.

[Stefan|IA2]

het gaat hierbij om Servage.net en ik ben het er ook aardig zat inmiddels... (na 1 week al) Ook al is het voor iemand anders, het moet wel goed werken...

[ Voor 74% gewijzigd door Stefan|IA2 op 17-09-2009 10:19 ]

[Cartman!]

Dan adviseer je die ander om te verhuizen naar een goede hostingprovider.

[dwilmer]

Anders kun je (alleen om te testen, er staat nogal wat info in) de servervars uitprinten met print_r:

PHP:

<?php
print_r($_SERVER);
?>

Dit ziet alleen redelijk uit in de broncode, je browser verwijdert voor het renderen uiteraard alle whitespace. Als je het netjes in je browser wilt zien zou je dit kunnen gebruiken:

PHP:

<?php
$serverVars = print_r($_SERVER, true);
$serverVars = str_replace(" ", "&nbsp;", $serverVars);
$serverVars = str_replace("\n", "<br />", $serverVars);
echo $serverVars;
?>

Dan kun je makkelijk het verschil bekijken tussen de http-request en de https-request, en kun je daarop filteren.

EDIT: aantal posts niet gelezen. Moet beter kijken naar het aantal pagina's. Blijft het alsnog een goede manier om even je servervars te bekijken, maar nu een beetje achterhaald.

[ Voor 12% gewijzigd door dwilmer op 26-09-2009 21:37 ]

[pedorus]

dwilmer schreef op zaterdag 26 september 2009 @ 21:33:
Blijft het alsnog een goede manier om even je servervars te bekijken, maar nu een beetje achterhaald.

Ehm, heb je wel eens goed naar de output van phpinfo() gekeken?

[Erkens]

offtopic:

dwilmer schreef op zaterdag 26 september 2009 @ 21:33:
Dit ziet alleen redelijk uit in de broncode, je browser verwijdert voor het renderen uiteraard alle whitespace. Als je het netjes in je browser wilt zien zou je dit kunnen gebruiken:

PHP:

<?php
$serverVars = print_r($_SERVER, true);
$serverVars = str_replace(" ", "&nbsp;", $serverVars);
$serverVars = str_replace("\n", "<br />", $serverVars);
echo $serverVars;
?>

pff, ik doe dan liever iets als:

PHP:

echo '<pre>',var_export($_SERVER, true),'</pre>';

dat is iets minder werk voor dit soort simpele debug zaken als je dat perse even wilt uitvoeren.

[wjzijderveld]

Je zou ook nog parse_url kunnen gebruiken.