Vraag Is er een reden om HTTPS niet op een website af te dwingen?


Een website die ik vaak gebruik, heeft eindelijk besloten om TLS in te schakelen op hun servers, maar niet om het te autoriseren zoals veel websites die doen. De beheerder beweert dat TLS moet optioneel zijn. Waarom?

Op mijn eigen website heb ik lange tijd verplichte TLS en HSTS opgezet en de zwakkere cipher-suites zijn uitgeschakeld. Open-teksttoegang is gegarandeerd omsloten met een HTTP 301 naar de met TLS beveiligde versie. Heeft dit een negatief effect op mijn website?


49
2018-04-01 13:46


oorsprong


Ze kunnen vrezen, dat HSTS hen in de problemen zal brengen, als er iets fout gaat (dat wil zeggen, hun gratis CA stopt met het uitgeven van certificaten of wordt verwijderd uit browsergelast winkels vanwege een probleem). Met het huidige TLS-ecosysteem maakt u afhankelijkheden aan de vertrouwde CA's / de browserleveranciers. Het is momenteel moeilijk te vermijden en de moeite waard, maar je kunt dit nog steeds zien als een probleem en HTTPS niet afdwingen als een oplossing om onafhankelijk te blijven voor het geval er iets gebeurt. - allo
iedereen wil de eis van tls voor h2 vermelden, die veel sneller is dan http1.1. goed voor je doet hsts, ik heb onlangs mijn site gestuurd voor de hsts preload lijst, hopelijk kan ik poort 80 gewoon allemaal uitschakelen - Jacob Evans
Zie dit: security.stackexchange.com/questions/53250/... - d33tah
@gerrit Dit argument staat niet voor goedkope en gratis certificaatautoriteiten zoals Let's Encrypt. - Maxthon Chan
Let's Encrypt werkt niet met elke host, en het is niet zo eenvoudig als het gebruik van een betere host. Ik gebruik App Engine die om technische redenen niet (direct) wordt ondersteund. - Carl Smith


antwoorden:


Er zijn verschillende goede redenen om TLS te gebruiken

(en slechts enkele marginale redenen om dit niet te doen).

  • Als de site enige verificatie heeft, gebruikt u HTTP Expose voor het stelen van sessies en wachtwoorden.
  • Zelfs op statische, louter informatieve sites zorgt het gebruik van TLS ervoor dat niemand met de gegevens heeft geknoeid.

  • Sinds Google I / O 2014, Heeft Google verschillende stappen ondernomen om alle sites aan te moedigen HTTPS te gebruiken:

  • Het Mozilla Security Blog heeft ook aangekondigd van Depreceren van niet-beveiligde HTTP door het maken van alle nieuwe functies die alleen beschikbaar zijn om websites te beveiligen en geleidelijk de toegang tot browserfuncties voor niet-beveiligde websites geleidelijk uitschakelen, met name functies die een risico vormen voor de veiligheid en privacy van gebruikers.

Er zijn ook verschillende goede redenen om TLS af te dwingen

Als u al een alom vertrouwd certificaat heeft, waarom zou u het dan niet altijd gebruiken? Vrijwel alle huidige browsers ondersteunen TLS en hebben rootcertificaten geïnstalleerd. Het enige compatibiliteitsprobleem dat ik in jaren heb gezien, zijn Android-apparaten en Ontbrekende tussenliggende certificeringsinstantie omdat Android alleen root CA's vertrouwt. Dit kan eenvoudig worden voorkomen door de server zodanig in te stellen dat hij de reeks certificaten terugstuurt naar de hoofdcertificeringsinstantie.

Als uw beheerder nog steeds HTTP-verbindingen zou willen toestaan ​​zonder direct 301 Moved Permanently, bijvoorbeeld voor het garanderen van toegang van enkele echt oude browsers of mobiele apparaten, er is geen manier voor de browser om te weten dat je zelfs HTTPS hebt geconfigureerd. Verder zou je niet moeten inzetten HTTP Strict Transport Security (HSTS) zonder 301 Moved Permanently:

7.2.  HTTP Request Type

   If an HSTS Host receives a HTTP request message over a non-secure
   transport, it SHOULD send a HTTP response message containing a status
   code indicating a permanent redirect, such as status code 301
   (Section 10.3.2 of [RFC2616]), and a Location header field value
   containing either the HTTP request's original Effective Request URI
   (see Section 9 "Constructing an Effective Request URI") altered as
   necessary to have a URI scheme of "https", or a URI generated
   according to local policy with a URI scheme of "https").

Het probleem van verschillende sites die voor beide protocollen zijn geconfigureerd, wordt herkend door Het Tor-project en de Electronic Frontier Foundation en geadresseerd door een multibrowser HTTPS overal uitbreiding:

Veel sites op internet bieden enige beperkte ondersteuning voor codering   HTTPS, maar maken het moeilijk om te gebruiken. Ze kunnen bijvoorbeeld standaard naar   niet-versleutelde HTTP, of vul gecodeerde pagina's met links waarnaar teruggaat   de niet-versleutelde site.

Gemengde inhoud was ook een enorm probleem vanwege mogelijke XSS-aanvallen op HTTPS-sites door het aanpassen van JavaScript of CSS die via een niet-beveiligde HTTP-verbinding is geladen. Daarom waarschuwen tegenwoordig alle gangbare browsers gebruikers voor pagina's met gemengde inhoud en weigert deze automatisch te laden. Deze maakt het moeilijk om een ​​site te onderhouden zonder de 301 omleidingen op HTTP: u moet ervoor zorgen dat elke HTTP-pagina alleen HTTP-contect (CSS, JS, afbeeldingen enz.) laadt en elke HTTPS-pagina laadt alleen HTTPS-inhoud. Dat is extreem moeilijk om te bereiken met dezelfde inhoud op beide.


8
2018-04-01 15:25



If your maintainer still would like to allow HTTP connections without direct 301 Moved Permanently, say for ensuring access from some really old browsers or mobile devices, HSTS is the correct choise as it only enforces HTTPS when it is clear that the browser supports it maar in dit geval zal de client (zelfs HTTPS-compatibel) nooit weten dat de HTTPS-versie aanvankelijk HTTP laadt. - Cthulhu
Re your last paragraph: HSTS-header wordt genegeerd tijdens niet-HTTPS-verbinding. - Cthulhu
HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport.  If an HTTP response is received over insecure transport, the UA MUST ignore any present STS header field(s).  tools.ietf.org/id/draft-ietf-websec-strict-transport-sec-14.txt - Cthulhu
Bedankt voor het wijzen op mijn valse hint, Cthulhu! Geïnspireerd door dat, heb ik mijn antwoord aanzienlijk verbeterd. Wees alsjeblieft ook welkom om kritisch te zijn naar de nieuwe inhoud. :) - Esa Jokinen


In deze tijd zijn TLS + HSTS-markeringen dat uw site wordt beheerd door professionals die kunnen worden vertrouwd om te weten wat ze doen. Dat is een opkomende minimumnorm voor de betrouwbaarheid, zoals blijkt uit Google, waarin staat dat ze een positieve beoordeling geven voor sites die dit doen.

Aan de andere kant is maximale compatibiliteit. Er zijn nog steeds oudere klanten, vooral in delen van de wereld die niet de Verenigde Staten, Europa of China zijn. Gewoon HTTP zal altijd werken (hoewel niet altijd werken goed; dat is een ander verhaal).

TLS + HSTS: Optimaliseren voor het rangschikken van zoekmachines
Gewoon HTTP: Optimaliseren voor compatibiliteit

Afhankelijk van wat belangrijker voor u is.


62
2018-04-01 13:59



Misschien ben ik kieskeurig, maar die eerste zin lijkt me een beetje op niets uit te lopen: een site die https is, zegt niets over het professionalisme of de betrouwbaarheid van de mensen die de leiding hebben. Een site kan https zijn en nog steeds worden ontwikkeld / beheerd door mensen die de invoer niet saneren, waardoor de site kwetsbaar is voor SQL-injectie of XSS; of het kan https zijn en ongeldig, niet toegankelijk of niet bruikbaar zijn. - Alvaro Montoro
Het gebruik van HTTPS is geen garantie voor professionaliteit, maar het gebrek daaraan zegt zeker het tegenovergestelde. - Esa Jokinen
Het gebruik van TLS en HSTS zijn signalen, die deel uitmaken van een veel grotere reeks, dat de site misschien de moeite van het lezen waard is. In tegenstelling tot anderen, zijn trivially gemakkelijk om voor de aanwezigheid van te testen, dus daarom gebruikt Google dit als een proxy voor de rest. - sysadmin1138♦
@Braiam Stack Exchange migreert alleen naar https en zal binnenkort hsts gaan gebruiken. Http is nog steeds beschikbaar, niet vanwege compatibiliteit, maar omdat ze traag en voorzichtig zijn en het technisch moeilijk is om te migreren. - captncraig
@esajohnson - gebrek aan https toont geen onprofessioneel karakter. Het laat zien dat er geen "noodzaak" voor is. Bijvoorbeeld een CentOS-spiegel. - warren


Er is één goede reden voor eenvoudig alleen lezen websites om geen gebruik te maken van HTTPS.

  • Web-caches kunnen afbeeldingen die via HTTPS worden getransporteerd niet cachen.
  • Sommige delen van de wereld hebben zeer lage internationale verbindingen, dus zijn afhankelijk van de caches.
  • Het hosten van afbeeldingen van een ander domein vereist vaardigheden die u niet voor kleine bedrijven kunt verwachten alleen lezen websites te hebben.

31
2018-04-01 23:30



Alleen-lezen-inhoud kan op CDN worden geïmplementeerd als u deze landen target. Het CDN weerspiegelt de statische inhoud op hun eigen manier en dient ze nog steeds via HTTPS. CDN is vrij eenvoudig te vinden en voor kleine websites niet zo duur om te gebruiken. - Maxthon Chan
@MaxthonChan, probeer mijn moeder uit te leggen wat een CDN is ..... Toch kan ze een website opzetten met de tijden van plaatselijke kerkdiensten. - Ian Ringrose
@MichaelHampton hoe kan een cache de afbeelding lezen van een HTTPS-stream zonder de beschrijvingscodes te hebben? En zou u een ISP vertrouwen met uw sleutels? - Ian Ringrose
Je moet duidelijker maken aan welke caches je het hebt. - Michael Hampton♦
@IanRingrose Als je moeder een website met lokale kerkdienstinfo opzet, is het onwaarschijnlijk dat cachinggedrag op internationale verbindingen een rol gaat spelen, tenzij het een erg populaire kerk is. - Jason C


De beheerder beweert dat TLS optioneel moet zijn. Waarom?

Om het antwoord op deze vraag echt te kennen, moet je het ze vragen. We kunnen echter wel raden.

In bedrijfsomgevingen is het gebruikelijk dat IT een firewall installeert die verkeer inkomende en uitgaande inspecteert op malware, verdachte CnC-achtige activiteit, inhoud die ongeschikt wordt geacht voor werk (bijvoorbeeld pornografie), enz. Dit wordt veel moeilijker wanneer het verkeer wordt gecodeerd. Er zijn in wezen drie mogelijke antwoorden:

  1. Geef op bij het monitoren van dit verkeer.
  2. Installeer een root-CA op de computers van gebruikers, zodat u MitM-decodering en inspectie kunt uitvoeren.
  3. Groothandel blok gecodeerd verkeer.

Voor een betrokken sysadmin zijn geen van deze opties bijzonder aantrekkelijk. Er zijn veel bedreigingen die een bedrijfsnetwerk aanvallen en het is hun taak om het bedrijf tegen hen te beschermen. Het blokkeren van een groot aantal sites verhoogt echter de gebruikersrechtensituatie en het installeren van een hoofd-CA kan een beetje nep zijn, omdat het privacy- en beveiligingsoverwegingen voor gebruikers introduceert. Ik herinner me dat ik een sysadmin-petitie reddit (reddit) zag toen ze voor het eerst HSTS aanzetten omdat hij precies in deze situatie verkeerde en niet alle reddit wilde blokkeren omdat hij door het bedrijf werd gedwongen om de porno-gefocuste subreddits te blokkeren.

De wielen van de technologie blijven maar doorklinken en je zult velen tegenkomen die beweren dat dit soort bescherming ouderwets is en geleidelijk moet worden afgeschaft. Maar er zijn er nog steeds veel die het beoefenen, en misschien zijn zij het met wie uw mysterieuze onderhouder is.


14
2018-04-01 18:16



hoe zit het met het beëindigen van SSL op de frontend-server / load-balancer / soortgelijk en daarna het verkeer loggen? - eis
@eis Dat veronderstelt dat het bedrijf elke website beheert die werknemers kunnen bezoeken, wat onwaarschijnlijk is. Het bericht lijkt niet te gaan over TLS op een intranetwebsite. - Xiong Chiamiov


Het komt allemaal aan op uw beveiligingsvereisten, gebruikerskeuze en het risico van impliciete downgrading. Het uitschakelen van oude coderingen aan de serverzijde is grotendeels noodzakelijk omdat browsers met plezier in de naam van de gebruikerservaring / het gemak tot absoluut vreselijke coderingen client-kant zullen vallen. Zorg ervoor dat niets van jou dat ligt eraan op een beveiligd kanaal naar de gebruiker kan niet worden bereikt met een onzekere methode is natuurlijk ook erg goed.

Staat me niet toe om expliciet te downgraden naar onveilige HTTP wanneer ik vind dat je blogpost over waarom je meer van Python houdt dan van Ruby (niet zeggen dat je dat doet, alleen een generiek voorbeeld) niet iets is dat ik op de spoken let of dat het publiek weet Ik heb toegang gekregen, zit me gewoon in de weg, zonder de goede reden, in de veronderstelling dat HTTPS voor mij triviaal zal zijn.

Er zijn vandaag ingesloten systemen die niet de mogelijkheid hebben om TLS out of the box te gebruiken, of degenen die vastzitten op oude implementaties (ik vind het erg slecht dat dit zo is, maar als een krachtige gebruiker van [insert embedded] apparaat hier], ik kan dit soms niet wijzigen).

Dit is een leuk experiment: probeer een recente versie van LibreSSL te downloaden van de upstream OpenBSD-site via HTTPS met een voldoende oude TLS / SSL-implementatie. Dat zal je niet kunnen. Ik probeerde de andere dag op een apparaat met een oudere versie van OpenSSL vanaf 2012 of zo, omdat ik dit ingesloten systeem wilde upgraden naar veiliger nieuwe dingen van de bron - ik heb niet de luxe van een vooraf gebouwd pakket. De foutmeldingen toen ik het probeerde waren niet bepaald intuïtief, maar ik neem aan dat dit kwam omdat mijn oudere OpenSSL de juiste dingen niet ondersteunde.

Dit is een voorbeeld waarbij de enige verhuizing-HTTPS mensen kan benadelen: als je niet de luxe hebt van recente kant-en-klare pakketten en het probleem zelf wilt oplossen door te bouwen vanaf de bron, ben je buitengesloten. Gelukkig kun je in de LibreSSL-zaak terugvallen op het expliciet aanvragen van HTTP. Natuurlijk, dit zal je niet redden van een aanvaller die je verkeer al herschrijft, in staat is bronpakketten te vervangen door gecompromitteerde versies en alle checksums in HTTP-lichamen herschrijft die de pakketten beschrijven die te downloaden zijn op de webpagina's die je bladert, maar het is nog steeds nuttig in de veel meer algemene zaak.

De meesten van ons zijn niet één onbeveiligde download verwijderd van het bezit van een APT (Advanced Persistent Thread: beveiligingsjargon voor nationale inlichtingendiensten en andere extreem goed uitgeruste cyberbedreigingen). Soms wil ik het gewoon wget enkele platte tekstdocumentatie of een klein programma waarvan ik de bron snel kan controleren (mijn eigen kleine utilities / scripts op GitHub, bijvoorbeeld) op een vak dat de nieuwste cipher-suites niet ondersteunt.

Persoonlijk zou ik dit vragen: is uw inhoud zodanig dat een persoon op legitieme wijze kan beslissen: "Ik vind het goed dat ik toegang heb tot publieke kennis"? Is er een aannemelijke kans op een reëel risico voor niet-technische mensen die per ongeluk downgraden naar HTTP voor uw inhoud? Weeg uw beveiligingseisen, afgedwongen privacy-voor-uw-gebruikersvereisten en het risico van impliciete downgrades af tegen het vermogen van gebruikers die de risico's begrijpen die van geval tot geval een geïnformeerde keuze maken om onbeveiligd te gaan. Het is volkomen legitiem om te zeggen dat er voor uw site geen goede reden is om HTTPS niet af te dwingen, maar ik denk dat het redelijk is om te zeggen dat er nog steeds goede use-cases voor gewone HTTP zijn.


5
2018-04-02 18:12



"probeer een recente versie van LibreSSL te downloaden vanaf de upstream OpenBSD-site via HTTPS met een voldoende oude TLS / SSL-implementatie" De keerzijde hiervan is natuurlijk: probeer een recente browser te downloaden met een voldoende oude browser, bijvoorbeeld een browser die alleen HTTP / 1.0 implementeert zonder ondersteuning voor de Host: header. Of probeer moderne sites te surfen met een webbrowser die alleen de Javascript van 2001 ondersteunt. Op een gegeven moment moeten we als community verder gaan, wat helaas voor sommigen onderbrekingen oplevert. De vraag wordt dan: is de toegevoegde waarde de breuk waard? - α CVn
@ MichaelKjörling Dat zijn ook problemen, van verschillende ernst. Ik zal toevoegen aan het bouwen van recente compilerversies aan die lijst. Sommige zijn meer verdedigbaar dan andere. Ik weet niet zeker of u het oneens bent of waarom: als u in de tweede zin van mijn functie bent, ga ik ermee akkoord dat is gerechtvaardigd om oude cijfers op een HTTPS-verbinding te voorkomen, omdat het de meeste gebruikers beschermt tegen downgrade-aanvallen waarvoor ze anders geen zinvol zicht zouden hebben of die ze zouden verdedigen. (Ik denk niet dat de meeste moderne websites die niet gracieus worden afgebroken op afstand gerechtvaardigd zijn, maar dat is een beetje naast het punt.) - mtraceur
@ MichaelKjörling Om te verduidelijken, het punt om dat naar voren te brengen, was omdat het een voorbeeld is van waar het bieden van eenvoudige HTTP voor de gebruiker had een duidelijk voordeel, dat was het kernpunt van de vraag die werd beantwoord. Het was op geen enkele manier een negatief licht op de OpenBSD / LibreSSL-projecten te werpen, waarvoor ik behoorlijk veel respect heb. Ik dacht dat de tweede zin van de eerste alinea een dergelijke negatieve interpretatie zou hebben uitgesloten. Als je denkt dat dit onduidelijk was of beter kon worden geformuleerd, reageer dan gerust op mijn antwoord of stel verbeteringen voor. - mtraceur


Er is hier veel discussie over waarom tls goed is - maar dat is nooit gevraagd zoals in de oorspronkelijke post.

Maxthon stelde 2 vragen:

1) waarom heeft een willekeurige, niet-genoemde site besloten om zowel http als https-presences te onderhouden

2) Heeft Maxthon een negatieve invloed op slechts 301 antwoorden op http-verzoeken

Met betrekking tot de eerste vraag weten we niet waarom de providers ervoor kozen om zowel http- als https-sites te behouden. Er kunnen veel redenen zijn. Naast de punten over compatibiliteit, gedistribueerde caching en enkele hints over geopolitieke toegankelijkheid, is er ook aandacht voor inhoudintegratie en het vermijden van lelijke browserberichten over het onveilig zijn van de inhoud. Zoals Alvaro al aangaf, is TLS slechts het topje van de ijsberg met betrekking tot beveiliging.

De tweede vraag is echter verantwoording. Blootstelling van een deel van uw site van uw website via http wanneer het daadwerkelijk https vereist voor een veilige werking, biedt een exploiteerbare vector voor aanvallen. Het heeft echter enige zin om dit te handhaven om te identificeren waar verkeer verkeerd wordt doorgestuurd naar poort 80 op uw site en om de oorzaak vast te stellen. D.w.z. er is zowel een negatieve impact als de mogelijkheid voor een positieve impact, het nettoresultaat is afhankelijk van of u uw werk als beheerder doet.

Sysadmin1138 zegt dat https van invloed is op SEO-ranglijsten. Hoewel Google heeft verklaard dat het invloed heeft op de ranglijst, de enige betrouwbare studies Ik heb gezien dat het verschil klein is. Dit wordt niet door mensen geholpen wie zou beter moeten weten beweren dat, omdat op de top geplaatste sites meer kans hebben op een https-aanwezigheid, een aanwezigheid van https daarom verbetert rankings.


3
2018-04-03 22:52





In het verleden moest ik HTTP gebruiken in plaats van HTTPS, omdat ik dat wilde <embed> pagina's van elders die zelf via HTTP zijn ontvangen en anders niet werken.


1
2018-04-04 11:52



U kunt uw server gebruiken om proxy een SSL-versie terug te draaien. - Maxthon Chan


Dit is geen goed reden, omdat het betekent dat u slechte / kapotte / onzekere klanten hebt, maar als er geautomatiseerde processen zijn die via het bestaande toegang hebben tot bronnen http:// urls, het is mogelijk dat sommige van hen zelfs geen ondersteuning bieden voor https (bijv. busybox wget, dat intern geen TLS-ondersteuning heeft en dit pas recentelijk via een openssl-kinderproces heeft toegevoegd) en zou breken als ze een omleiding kregen naar een https-URL die ze niet kunnen volgen.

Ik zou in de verleiding komen om met deze mogelijkheid om te gaan door de omleidingsregel te schrijven om onbekende (of bekende-legacy) User-Agent-strings uit te sluiten en door te laten gaan tot de inhoud via http als ze dat willen, zodat echte browsers allemaal kunnen profiteren gedwongen https / hsts.


1
2018-04-03 16:08



Herinner me eraan hoeveel tientallen jaren geleden elke goed onderhouden tool (bijvoorbeeld wget) geen ondersteuning bood voor HTTPS? - Oleg V. Volkov
@ OlegV.Volkov: Ik denk dat je het woord busybox hebt gemist in mijn antwoord. - R..
Gecontroleerd - nou, nu zie ik het. Ik begrijp niet echt waarom dan niet alleen dat verdomde ding kan bouwen en dan geen hulpmiddelen voor het bouwen van pakketten, maar wat dan ook. Terugdenkend Ik herinnerde me ook enkele gevallen waarin mensen zich beperkten tot uitgeklede of verouderde hulpmiddelen en het zou goed zijn om gewoon HTTP te hebben. Kunt u de caps alsjeblieft corrigeren, zodat ik ook na de bewerking de stemming kan terugdraaien? - Oleg V. Volkov


Er zijn maar weinig goed redenen voor het gebruik van HTTP in plaats van HTTPS op een website. Als uw website transacties van welke aard dan ook behandelt of gevoelige of persoonlijke gegevens opslaat, moet u absoluut HTTPS gebruiken als u wilt dat de gegevens veilig zijn. De enige goede reden die ik zou zien voor het afdwingen van HTTPS is als uw website afhankelijk is van caching omdat HTTPS niet werkt met caching. Het is echter vaak de moeite waard een beetje op te offeren om de veiligheid van uw website te garanderen. Het is ook mogelijk dat uw klanten HTTPS niet ondersteunen, maar in 2017 zouden ze dat wel moeten doen.


1
2018-04-07 16:25