Security Professionals
- ipfw add deny all from eindgebruikers to any
HSTS
Goede morgen,
Vanmorgen volgende regel aan een apache virtualhost (ssl-enabled) config toegevoegd:
Header add Strict-Transport-Security: "max-age=63072000; includeSubDomains"
Er is ook voor dezelfde site een virtualhost zonder ssl enabled.
Apache herstart.
Eerst maar eens naar de niet-SSL site gegaan.
Werkt natuurlijk prima. (ik heb expres geen rewriterule o.i.d. voor http-->https gezet, omdat ik wil zien wat de browser doet)
Dan naar de ssl enabled site.
Doet het ook. Middels live-http-headers zie ik dat de nieuwe header keurig wordt opgevoerd.
Dan nu weer terug naar de niet-ssl site. Mijn verwachting is dat de browser nu zal protesteren, want deze heeft (als het goed is) de header van de vorige sessie onthouden. Ik zou dus op z'n minst een waarschuwing van de browser verwachten.
Dat gebeurt dus niet :-( Ik wordt zonder meer doorgelaten naar de niet-ssl site.
De gebruikte browser is iceweasel (firefox op debian). En ook chromium geprobeerd. Beide zelfde (teleurstellende) resultaat
Mijn vragen:
1 - Doe ik iets fout? (die kans acht ik het grootst)
2 - Moet ik toch nog ergens iets aanzetten in de browsers?
3 - Ik gebruik een Self Signed Certificate (Huis, tuin en keuken proefopstelling). Kan dat er iets mee te maken hebben?
Als iemand een pointer o.i.d. heeft, dan lees ik het erg graag.
Met vriendelijke groet,
Martijn
Vanmorgen volgende regel aan een apache virtualhost (ssl-enabled) config toegevoegd:
Header add Strict-Transport-Security: "max-age=63072000; includeSubDomains"
Er is ook voor dezelfde site een virtualhost zonder ssl enabled.
Apache herstart.
Eerst maar eens naar de niet-SSL site gegaan.
Werkt natuurlijk prima. (ik heb expres geen rewriterule o.i.d. voor http-->https gezet, omdat ik wil zien wat de browser doet)
Dan naar de ssl enabled site.
Doet het ook. Middels live-http-headers zie ik dat de nieuwe header keurig wordt opgevoerd.
Dan nu weer terug naar de niet-ssl site. Mijn verwachting is dat de browser nu zal protesteren, want deze heeft (als het goed is) de header van de vorige sessie onthouden. Ik zou dus op z'n minst een waarschuwing van de browser verwachten.
Dat gebeurt dus niet :-( Ik wordt zonder meer doorgelaten naar de niet-ssl site.
De gebruikte browser is iceweasel (firefox op debian). En ook chromium geprobeerd. Beide zelfde (teleurstellende) resultaat
Mijn vragen:
1 - Doe ik iets fout? (die kans acht ik het grootst)
2 - Moet ik toch nog ergens iets aanzetten in de browsers?
3 - Ik gebruik een Self Signed Certificate (Huis, tuin en keuken proefopstelling). Kan dat er iets mee te maken hebben?
Als iemand een pointer o.i.d. heeft, dan lees ik het erg graag.
Met vriendelijke groet,
Martijn
Reacties (11)
Per website moet de header ingesteld worden, het configuratie bestand staat meestal in /etc/nginx/sites-available/.
server {
listen 443 ssl default deferred;
...
# config to enable HSTS(HTTP Strict Transport Security)
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains;";
...
}
De toevoeging van de includeSubDomains optie zorgt er voor dat de browser nu voor alle subdomeinen van de website ook via HTTPS wil verbinden. Het weglaten van deze optie voorkomt dat, maar is niet aan te raden.
Info credits Networking4All
server {
listen 443 ssl default deferred;
...
# config to enable HSTS(HTTP Strict Transport Security)
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains;";
...
}
De toevoeging van de includeSubDomains optie zorgt er voor dat de browser nu voor alle subdomeinen van de website ook via HTTPS wil verbinden. Het weglaten van deze optie voorkomt dat, maar is niet aan te raden.
Info credits Networking4All
Bij gebruik van HSTS krijg je geen melding of zo vanuit de browser; als je naar de http versie gaat terwijl er een HSTS header is gezet plakt je browser zelf de 's' er achter en gaat naar de https versie. Je ziet hier als gebruiker verder niks van behalve dat de url is omgezet naar https.
Weet je dus zeker dat je op de http versie zit?
Weet je dus zeker dat je op de http versie zit?
Heb geen ervaring met Apache, maar even simpel gezegd dacht ik dat in het algemeen bij gebruik van HSTS de hele hostserver achter hetzelfde IP-adres (alleen maar) ssl-enabled moet zijn. Anders werkt het niet.
Voor wat betreft self signed certificates bij HSTS: zie paragraaf 11.3 van RFC6797: http://tools.ietf.org/html/rfc6797
Goeroehoedjes
Voor wat betreft self signed certificates bij HSTS: zie paragraaf 11.3 van RFC6797: http://tools.ietf.org/html/rfc6797
Goeroehoedjes
11-09-2015, 14:42 door
maboc
Door Anoniem: Per website moet de header ingesteld worden, het configuratie bestand staat meestal in /etc/nginx/sites-available/.
server {
listen 443 ssl default deferred;
...
# config to enable HSTS(HTTP Strict Transport Security)
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains;";
...
}
De toevoeging van de includeSubDomains optie zorgt er voor dat de browser nu voor alle subdomeinen van de website ook via HTTPS wil verbinden. Het weglaten van deze optie voorkomt dat, maar is niet aan te raden.
Info credits Networking4All
Da's denk ik wat ik ook zei (maar dan iets meer info)...maar nu voor nginx als http engine :-)server {
listen 443 ssl default deferred;
...
# config to enable HSTS(HTTP Strict Transport Security)
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains;";
...
}
De toevoeging van de includeSubDomains optie zorgt er voor dat de browser nu voor alle subdomeinen van de website ook via HTTPS wil verbinden. Het weglaten van deze optie voorkomt dat, maar is niet aan te raden.
Info credits Networking4All
Door Anoniem: Bij gebruik van HSTS krijg je geen melding of zo vanuit de browser; als je naar de http versie gaat terwijl er een HSTS header is gezet plakt je browser zelf de 's' er achter en gaat naar de https versie. Je ziet hier als gebruiker verder niks van behalve dat de url is omgezet naar https.
Weet je dus zeker dat je op de http versie zit?
Weet je dus zeker dat je op de http versie zit?
De URL is nog precies wat deze was: dus zonder https. (Ook geen slotje oid. in de URL balk).
Maar .... je brengt me op een idee. Zo wireshark maar eens aanzetten om te zien wat er nu daadwerkelijk over de lijn gaat.
tnx
Door Anoniem: Heb geen ervaring met Apache, maar even simpel gezegd dacht ik dat in het algemeen bij gebruik van HSTS de hele hostserver achter hetzelfde IP-adres (alleen maar) ssl-enabled moet zijn. Anders werkt het niet.
Voor wat betreft self signed certificates bij HSTS: zie paragraaf 11.3 van RFC6797: http://tools.ietf.org/html/rfc6797
Goeroehoedjes
Met deel een (1) van je schrijven ben ik het niet geheel eens. Juist als je ook nog de mogelijkheid hebt om niet-ssl verkeer te gebruiken, wordt het interessant om iets als HSTS in te zetten (waarmee langzaam alle niet-SSL/TLS van je site verdwijnt)Voor wat betreft self signed certificates bij HSTS: zie paragraaf 11.3 van RFC6797: http://tools.ietf.org/html/rfc6797
Goeroehoedjes
Snel even die rfc doorgelezen (uh...nouja...alleen 11.3).
Ik denk inderdaad dat het met mijn huis/tuin en keuken opzet (lees self signed certificate) te maken heeft.
Ik ga die rfc maar eens even goed lezen.
Dank voor je input.
Zegt je browser console toevallig nog iets?
Was een redirect niet juist verplicht om de header te laten werken?
Om te testen kun je beter een korte time-out gebruiken.
Was een redirect niet juist verplicht om de header te laten werken?
Om te testen kun je beter een korte time-out gebruiken.
Met deel een (1) van je schrijven ben ik het niet geheel eens. Juist als je ook nog de mogelijkheid hebt om niet-ssl verkeer te gebruiken, wordt het interessant om iets als HSTS in te zetten (waarmee langzaam alle niet-SSL/TLS van je site verdwijnt)
Dacht niet dat HSTS hiervoor bedoeld was. Alleen de naam: "HTTP Strict Transport Security" doet dit al vermoeden.Weet niet meer zeker of het bij wat ik eerder zei nu om Host IP-adres ging, of Domein incl. subdomeinen of beide.
Maar zal als het zo is ongetwijfeld wel ergens in RFC6797 staan. (vermoedelijk in wat uitgebreidere bewoordingen). ;-)
Goeroehoedjes
ho wacht... negeer mijn vorige bericht.
HSTS laat zich identificeren op het domeinniveau. Niet op IP niveau. Sorry.
Het is alleen dat het niet wordt aanbevolen om HSTS te combineren met HTTP subdomeinen. Dát bedoelde ik.
Dit had je ook al goed geconfigureerd met parameter "includeSubDomains" zo te zien.
Vraag is nog wel welke domeinnaam je gebruikt voor de "HTTP" virtual host, en of dit niet conflicteert?
En daarbij het selfsigned certificaten gedeelte zoals getipt. RFC6797 geeft je hopelijk raad. Succes!
Goeroehoedjes
HSTS laat zich identificeren op het domeinniveau. Niet op IP niveau. Sorry.
Het is alleen dat het niet wordt aanbevolen om HSTS te combineren met HTTP subdomeinen. Dát bedoelde ik.
Dit had je ook al goed geconfigureerd met parameter "includeSubDomains" zo te zien.
Vraag is nog wel welke domeinnaam je gebruikt voor de "HTTP" virtual host, en of dit niet conflicteert?
En daarbij het selfsigned certificaten gedeelte zoals getipt. RFC6797 geeft je hopelijk raad. Succes!
Goeroehoedjes
Door Anoniem: Was een redirect niet juist verplicht om de header te laten werken?
Nee, het hele idee achter hsts is juist dat je geen redirect nodig hebt en alle http verkeer vanuit de browser al voorkomt.
12-09-2015, 08:52 door
Erik van Straten
11-09-2015, 09:57 door maboc: Header add Strict-Transport-Security: "max-age=63072000; includeSubDomains"
Ik vermoed dat die dubbele punt er niet in hoort (zo onderdeel uitmaakt van de naam (identifier)). Probeer ook eens "includeSubDomains" te wijzigen in "includeSubdomains" (zou case-insensitive moeten zijn volgens RFC maar better safe than sorry) en er een puntkomma achter te zetten, dus als volgt:Header add Strict-Transport-Security "max-age=63072000; includeSubdomains;"
Een iets ander voorbeeld uit https://raymii.org/s/tutorials/HTTP_Strict_Transport_Security_for_Apache_NGINX_and_Lighttpd.html
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
Het is veiliger om "Header set" te gebruiken dan "Header add" omdat Apache vaak .conf files include en de kans bestaat dat iets of iemand een header met identieke naam toevoegt. Precies dat heb ik een keer gezien (met andere parameters) en dat leidde ertoe dat Firefox heel HSTS negeerde (de RFC stelt ook dat de header foutloos moet zijn).
Advies: copy/paste dit soort zaken vanaf betrouwbare pagina's op internet zoals RFC's of druk bezochte blogs met veel comments eronder, de kans op fouten is dan het kleinst.
Laat je het ons weten als je de fix gevonden hebt en wat dat was? Thanks!
Gebruik je een valide certificaat?
https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security:
When your site is accessed over HTTPS with no certificate errors, the browser knows your site is HTTPS capable and will honor the Strict-Transport-Security header.
https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security:
When your site is accessed over HTTPS with no certificate errors, the browser knows your site is HTTPS capable and will honor the Strict-Transport-Security header.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?