Ruller ut HTTPS til over tusen norske nettbutikker

[Harald Brombach (digi.no)]

Ruller ut HTTPS til over tusen norske nettbutikker

[-Night-]

Noe skurrer her, Apache støtter utmerket godt SNI....

Sies heller lite om hvordan det har CSR er generet eller andre rutiner rundt sikkerhet, så dette er i beste tilfelle lavsikkerhet oppsett. Hva med DNSSEC?

HSTS på den siden er også implementert på den dårlig måte den burde ha en preload samat includesubdomains direktiver utover redirigere fra http til https med headers slik at en altid veit at en bruker https dette hadde også tildels løst problment med hardkoded urler.

En A+ rangering på slike testsider har forsovet lite å si om totale sikkerheten rundt en nettside.
Siden har også forresten SNI som er feil konfigurert reff, SSL chain.


Dette virker uansett mest som reklamne framfor en faktisk nyhet.

Hadde uansett vært langt større nyhet om de hadde kommet med 100% IPv6 støtte i alle ledd. 

Endret 28. desember 2016 av -Night-

[Stian Didriksen]

Noe skurrer her, Apache støtter utmerket godt SNI....

 

Det er sant. Men Apache krever separate vhost blokker for port 80 og port 443 når du ønsker å støtte både http og https. Dette skapte utfordringer for oss da vår infrastruktur var automatisert rundt konseptet "en vhost per butikk".

En annen detalj er at vi bruker nginx i front for å kunne flytte butikker mellom servere alt ettersom hvor mye trafikk butikken får uten at vi må endre butikkens DNS konfigurasjoner.

Derfor valget vi å implementere SSL for våre butikker i nginx da nginx ikke bare støtter SNI men også både http og https i en og samme vhost blokk uten problem.

 

Sies heller lite om hvordan det har CSR er generet eller andre rutiner rundt sikkerhet, så dette er i beste tilfelle lavsikkerhet oppsett. Hva med DNSSEC?

 

CSR er det certbot (https://certbot.eff.org) som tar seg av. Den eksakte prosessen er godt dokumentert her: https://letsencrypt.org/how-it-works/

Vi har flere automatiserte sjekker før vi forsøker å hente LetsEncrypt sertifikat. Vi sjekker at alle domenene til en butikk peker til rett server samt at ip på hvert domene matcher server for å unngå at et domene en butikk ikke eier får sertifikat.

Ting som våre sjekker fanger opp som ikke certbot sin validering ikke fanger er blant annet om butikken ligger på en reverse proxy eller ikke.

Vi gjør flere steg for å gjøre kommunikasjonen over https (tls handshake osv) så trygg som det står til oss å gjøre den.

Dette innebærer at vi konfigurerer nginx til å ha en sterkere Diffie-Hellman key exchange for å unngå sårbarheter mot Logjam: https://weakdh.org

Vi har også et self-signed sertifikat som gjør at kommunikasjonen mellom nginx og apache alltid er kryptert. Dette er viktig da nginx i mange tilfeller kjører på en annen server enn butikkens apache-instans.

Ang DNSSEC så drifter vi bare apache og nginx servere, vi drifter ikke navnetjenere eller DNS relaterte ting. Det blir jo kundens domeneleverandør sitt ansvar å implementere det.

 

HSTS på den siden er også implementert på den dårlig måte den burde ha en preload samat includesubdomains direktiver utover redirigere fra http til https med headers slik at en altid veit at en bruker https dette hadde også tildels løst problment med hardkoded urler.

 

Vi drifter som sagt ikke hele domenet som en kunde har. For eks så peker store.starbucks.no til oss, men det gjør ikke starbucks.no eller andre underdomener starbucks har. Av denne grunn så kan vi ikke bruke "IncludeSubdomains" direktivet helt ukritisk.

Vi kommer til å starte med http til https redirects før nyttår, akkurat nå driver vi med å kvalitetssjekke og jobber oss igjennom edge-cases (dem er det mange eksterne faktorer vi ikke har kontroll over men likevel må ta stilling til, som for eks en domeneleverandørs hjemmelaga www til non-www redirects som tryner over https).

Preload direktivet "virker" ikke om man ikke følger stegene her: https://hstspreload.org

Der kreves blant annet at includeSubDomains er med, som betyr at preload er noe vi må tilby per kunde, ikke i global skala da mange av våre kunder har andre underdomener som ikke nødvendigvis har et gyldig sertifikat per dags dato da disse domenene kjører på andre servere som ikke driftes av oss.

 

Og når det gjelder hardkodede urls så gjelder ikke det bare urls som har med samme domene å gjøre. For eks så er det urls som gjør ajax kall til bring sitt api, klarna checkout iframe og mange andre ting som også må kjøre over https for å hindre mixed content.

Vi må også hjelpe kundene våre til å migrere egetprodusert innhold som produktbeskrivelser, statiske sider osv som inneholder bilder og annen media som bruker http://

 

en A+ rangering på slike testsider har forsovet lite å si om totale sikkerheten rundt en nettside.

 

Siden har også forresten SNI som er feil konfigurert reff, SSL chain.

 

A+ sier kun hvor bra selve ssl sertifikatet og konfigurasjonen er. En høy rangering betyr at man blant annet har sørget for å unngå sårbarheter som Logjam, Poodle med mer.

Det er bare en liten del av sikkerhetsbildet, det er jeg enig med deg i. Men det betyr ikke at det er uvesentlig, tvert imot burde det være et minstekrav.

 

Stiller spørrende til hvilket domene du påpeker har feilkonfigurasjon?

[-Night-]

Hei,,

 

Siden som er feil konfet er  den som er lenket til i innlegget til digi

 

https://www.ssllabs.com/ssltest/analyze.html?d=beautybrands.no&latest

 

Certificate #2: RSA 1024 bits (SHA256withRSA) No SNI

 

 

Når det gjelder certbot og CSR så er det et noe som ikke vekker tillit oss meg, for det vil i praksis si at privatekey ligger oss en trejdepart og ikke kun oss dere/kunden.   

 

Dere burde heller gener CSR selv og heller få den signert, som også er mulig med Lets Encrypt.. 

Siden du har lenket til er bare hardkoded preloading, den kan også legges inn i headers på nginx

 

add_header Strict-Transport-Security 'max-age=31536000; preload';

 

Ps i henhold til nye krav for 2017 for SSLLabs faller dere ned til rundt B- på den "testen"  grunnet dere at støtte før TLS 1.0  og en rekke dårlig ciphers.  Ja enig med at det burde være krav det er forsovet krav i USA i noen tilfeller (fips), men løpet mellom og ha en høy score på den og støtte for flere brukere går inne hånd  i hånd, jeg har selv satt opp en test server med mål om og få "100%" på alle tester, resultert av det er at det kun funker på det nyeste av enheter. 

 

 

https://blog.qualys.com/ssllabs/2016/11/16/announcing-ssl-labs-grading-changes-for-2017

 

http2 med apn kan også være fornuftig da det kutter ned på resursbruken ved bruk av TLS

 

listen 443 ssl http2;

listen [::]:443 ssl http2;

[henrikwl]

Poenget med Let's Encrypt er jo nettopp det helautomatiserte, -Night-. Skal man hoste stort mer enn en håndfull sites er det enormt krevende å skulle manuelt drive å styre med CSR-er og sertifikater. Let's Encrypt automatiserer hele prosessen for deg. Det er selve hovedpoenget.

[Stian Didriksen]

Ah ja det sertifikatet bruker vi som fallback for hovedsakelig to scenarioer:

1. Hvis en butikk ikke har et gyldig SSL sertifikat ennå så gjør vi en 301 redirect fra https til http.

2. Hvis det skjer en request uten SNI så gjør vi også en redirect fra https til http for at riktig vhost skal laste.

 

Har det en praktisk betydning om vi legger til et chain certificate på et self-signed sertifikat? https://whatsmychaincert.com/?beautybrands.no.24nb7.srv.ip.no

For da må vi jo gjøre noen justeringer

 

Når det gjelder CSR så har du et veldig godt poeng. Vi har planer om å få det på plass i neste omgang da det i verste fall fører til at det er sertifikater i omløp som har privatkey hos letsencrypt.

Hvis det var mulig å kombinere alternativet --allow-subset-of-names med --csr i certbot så ville saken vært enklere for oss.

Vår største utfordring er at veldig mange av våre kunder har et opplegg for www. underdomener, flere ulike domener pga at butikken har skiftet navn en eller flere ganger (eller har både .com, .no, se osv) og en kombinasjon av begge.

Når kundens DNS konfigurasjoner endrer seg så er det kritisk for oss at butikkens hoveddomene og domener som faktisk er i bruk og ikke bare brukes som redirects blir fornyet uten hiccups.

Det at man ikke per dags dato kan kombinere --csr og --allow-subset-of-names gjør at vi trenger mer tid på oss på å oppgradere vår infrastruktur til å håndtere jungelen av ekstra- og underdomener.

 

Takker for tips både om hsts preload og de nye kravene for SSL Labs.

Skal sørge for at vi får med preload.

 

Er enig i at det er ikke hensiktsmessig å fokusere så mye på å få toppkarakterer i forskjellige tester slik at det går på bekostning av tilgjengelighet.

Akkurat når det gjelder dagens krav for A+ gradering så mener vi at det harmonerer bra med de generelle kravene vi har til støttede enheter og nettlesere.

Foreløpig ser det ut til at dropping av TLS 1.0 ikke vil skje før Q3 i 2017, i mellomtiden holder vi godt øye med https://dev.ssllabs.com/ssltest/analyze.html?d=beautybrands.no for å passe på at vi følger med i timen.

 

http2 har vi veldig lyst å ta i bruk, men før vi kan det så må vår server-leverandør gjøre noen oppdateringer

[rosetta stoned]

Dette blir for teknisk for meg, er det ikke sikkert for meg å bruke f.eks. nettbanken?

 

Må jeg gjøre alle mine innkjøp fra beautybrands heretter

[Nimrad]

Dette blir for teknisk for meg, er det ikke sikkert for meg å bruke f.eks. nettbanken?

Joda, sikkert som banken.

[-Night-]

Ah ja det sertifikatet bruker vi som fallback for hovedsakelig to scenarioer:

1. Hvis en butikk ikke har et gyldig SSL sertifikat ennå så gjør vi en 301 redirect fra https til http.

2. Hvis det skjer en request uten SNI så gjør vi også en redirect fra https til http for at riktig vhost skal laste.

 

Har det en praktisk betydning om vi legger til et chain certificate på et self-signed sertifikat? https://whatsmychaincert.com/?beautybrands.no.24nb7.srv.ip.no

For da må vi jo gjøre noen justeringer

 

1. Hvorfor i det hele tatt ha et crt til slik? ved bruk av HSTS så vil det faile grunnet browser skal nekte og laste eller sider som i kke har gydlig crt. der HSTS er aktivert. 

2. Når en laster sine som har SNI med en browser uten SNI støtte så får man endten en feilside eller den siden som er primær side for servern som igjen feiler grunnet HSTS. 

 

Når det gjelder chain, så kan det føre til konflikter og ikke ha en signert chain. men slik browsere er idag er det ikke en stor sannsynlighet for det.  Det crt som dette gjelder er forresten ikke den del av LE chain men heller lastes som eget separat crt. her er det viktig og definere hvilke som blir lastet først.  

 

HPKP er noe som de fleste burde holde seg milevis unda grunnet gjør en feil der ødelegger man siden. 

Endret 28. desember 2016 av -Night-

[Bjørn A. Johansen]

Når det gjelder certbot og CSR så er det et noe som ikke vekker tillit oss meg, for det vil i praksis si at privatekey ligger oss en trejdepart og ikke kun oss dere/kunden.   

 

Maken til BS. Selv om du bruker Certbot med autogenerert CSR forlater aldri privkey maskinen som Certbot kjøres fra. Du vet ikke hva du snakker om.