Vraag Is het slecht om http om te leiden naar https?


Ik heb zojuist een SSL-certificaat op mijn server geïnstalleerd.

Vervolgens wordt een omleiding ingesteld voor al het verkeer op mijn domein op poort 80 om het om te leiden naar poort 443.

Met andere woorden, al mijn http://example.com verkeer wordt nu doorgestuurd naar de juiste https://example.com versie van de pagina.

De omleiding gebeurt in mijn Apache Virtual Hosts-bestand met iets als dit ...

RewriteEngine on
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R,L] 

Mijn vraag is: zijn er nadelen aan het gebruik van SSL?

Aangezien dit geen 301 Redirect is, verlies ik link juice / ranking in zoekmachines door over te schakelen naar https?

Ik waardeer de hulp. Ik heb altijd SSL op een server willen opzetten, alleen voor de praktijk om het te doen, en ik heb uiteindelijk besloten om het vanavond te doen. Het lijkt tot nu toe goed te werken, maar ik weet niet zeker of het een goed idee is om dit op elke pagina te gebruiken. Mijn site is geen eCommerce en behandelt geen gevoelige gegevens; het is vooral voor het uiterlijk en de sensatie om het te installeren voor leren.


GEACTUALISEERDE PROBLEEM

Vreemd genoeg maakt Bing dit screenshot vanaf mijn site nu dat het overal HTTPS gebruikt ...

enter image description here 


245
2018-01-28 00:12


oorsprong


[WTF - Ik kan geen antwoord toevoegen (hoewel ik voldoende rep heb). Mijn antwoord zou (gedeeltelijk) dat zijn SOMS IS HET SLECHT. Overweeg een COOKIE- of API-sleutel door te geven in een GET via HTTP. Als uw site HTTP-verzoeken doorverwijst naar HTTPS-aanvragen, werken deze oproepen, maar de COOKIE of API Key wordt verzonden in de clear-exposed. Sommige API's zetten HTTP uit, een meer robuuste aanpak - helemaal geen HTTP, dus je kunt het niet eens laten werken, tenzij je HTTPS gebruikt. Voorbeeld: "Alle API-aanvragen moeten worden gedaan via HTTPS. Gesprekken die via gewoon HTTP worden gemaakt, mislukken" stripe.com/docs/api?lang=php#authentication - codingoutloud
@codingoutloud - het alternatief is dat het hele ding gebeurt via HTTP zonder HTTPS. Hoe is dat beter? - Mark Henderson♦
@BenCrowell, dat komt omdat a captive portal lijkt ontzettend veel op een sslstrip-stijl omleidingsaanval (het zijn beide man-in-the-middle request-kapingen) dus HSTSbewuste browsers blokkeren ze allebei. - Jeffrey Hantin
Wees ervan bewust dat het gebruik van https betekent dat alles wat u opneemt ook https moet zijn of dat het mogelijk niet wordt geladen, bijv. jQuery laden met src="://example.com/jquery.js" - merk het ontbreken op van http of https dus de browser laadt de juiste. Ik had een nachtmerrie en probeerde sommige ingesloten Amazon-dingen correct te laden omdat de API (geladen via https) http-links produceerde - wat betekent dat ze niet goed werkten totdat ik de parameter zonder papieren vond om https-koppelingen te schakelen - Basic
Jason; je update zou een nieuwe vraag moeten zijn, waarschijnlijk op Webmastersomdat het (technisch) niets met uw oorspronkelijke vraag te maken heeft. Maar het is waarschijnlijk dat uw stylesheets afkomstig zijn van een onveilig domein. - Mark Henderson♦


antwoorden:


De [R] vlag op zichzelf is een 302 omleiding (Moved Temporarily). Als u echt wilt dat mensen de HTTPS-versie van uw site gebruiken (hint: u doet), dan zou u moeten gebruiken [R=301] voor een permanente omleiding:

RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R=301,L] 

EEN 301 houdt al je google-fu en zuurverdiende pageranks bij intact. Zorg ervoor dat mod_rewrite is ingeschakeld:

a2enmod rewrite

Om je exacte vraag te beantwoorden:

Is het slecht om http om te leiden naar https?

Echt niet. Het is zeer goed.


309
2018-01-28 00:27



Bedankt voor de informatie, mijn baas vertelt me ​​de reden dat hij alleen https op bepaalde pagina's van zijn site draait, is dat het veel meer serverbronnen gebruikt om het op elke pagina uit te voeren. Weet jij daar iets van of is dat waar? - JasonDavis
@jasondavis Alleen als je er geen paar minuten aan besteedt optimaliseren. - Michael Hampton♦
"het gebruikt veel meer serverbronnen om het op elke pagina te gebruiken." Moderne CPU's hebben coderingsversnellingsfuncties die SSL bijna gratis maken. Maak je geen zorgen over overhead. - Adam Davis
@AdamDavis Het crypto-algoritme is misschien licht van gewicht, maar de handshake-overhead bestaat nog steeds. Bovendien voorkomt HTTPS dat HTTP-proxy's uw inhoud in de cache opslaan. In meest gevallen is de overhead van HTTPS minimaal en de moeite waard, maar pas op voor over-generalisatie. - 200_success
Het doodt gedeelde caching, wat handig is voor de gebruikspatronen van sommige sites, en beschermt vaak weinig (is het belangrijk dat mensen kunnen weten dat je de site hebt bezocht, maar niet de details van wat je hebt gedaan? Dat is de enige situatie waar SSL nuttig is). Het belangrijkste voordeel van SSL op elke bron is niet dat u "beveiligt", bijvoorbeeld mensen kijken naar "over ons", maar dat je niet mag wegglippen en er niet in slaagt om het te gebruiken in een geval waar je zou moeten. - Jon Hanna


Hoewel ik het idee van alleen SSL-sites ondersteun, zou ik willen zeggen dat een nadeel overhead is, afhankelijk van het ontwerp van uw site. Ik bedoel bijvoorbeeld dat als u veel afzonderlijke afbeeldingen in img-tags gebruikt, dit ertoe kan leiden dat uw site veel langzamer werkt. Ik zou iedereen die SSL-only servers gebruikt adviseren om ervoor te zorgen dat ze op het volgende werken.

  1. Controleer de hele site op interne links en zorg ervoor dat ze allemaal HTTPS gebruiken als u uw eigen domeinnaam specificeert in links, dus u veroorzaakt geen eigen omleidingen.
  2. Update uw <meta property="og:url" om de https-versie van uw domein te gebruiken.
  3. Als je gebruikt <base href= opnieuw updaten om HTTPS te gebruiken.
  4. Installeren SPDY-protocol als dat mogelijk is
  5. Gebruik waar mogelijk CSS Image-sprites om het aantal verzoeken te verminderen.
  6. Werk uw sitemaps bij om de status van https aan te geven, zodat spiders na verloop van tijd deze wijziging te weten komen.
  7. Wijzig Zoekmachinevoorkeuren, zoals Google Webmasterhulpprogramma's, voor voorkeur voor HTTPS
  8. Sluit waar mogelijk alle stactische media uit naar HTTPS CDN-servers.

Als het bovenstaande is geadresseerd, dan betwijfel ik of u veel problemen zult hebben.


49
2018-01-28 02:08



SPDY is een goede suggestie; er lijkt zelfs een module te zijn SPDY-ondersteuning toevoegen aan Apache 2.x. - Calrion
"//Yourserver.com/some-uri" gebruiken in plaats van "yourserver.com/some-uri"lost probleem (1) op omdat de browser het juiste schema (http of https) kiest, afhankelijk van het schema waarmee de pagina is geladen. - MauganRa
@MauganRa Tenzij, natuurlijk, het is een link van bijvoorbeeld http-artikelpagina naar https-loginpagina. - Mołot
Google ziet de URL die iemand bezoekt via de Referer header. Deze site maakt bijvoorbeeld gebruik van jQuery van het CDN van Google en mijn browser stuurt een verzoek naar Google telkens wanneer ik de site herlaad. Daarbij een Referer header wordt ook verzonden naar Google, die is ingesteld op de URL van deze site. Dus Google kan de sites die ik bezoek volgen, terwijl mijn IP-adres niet verandert (en als ik in die tijd een Google-service gebruik, kan Google deze informatie ook verbinden met mijn Google-account). - Stephan Kulla
Voor 1) Ik heb net een zoekopdracht gedaan en vervangen in mijn MySQL-database http naar https ... ik gebruik WordPress, dus het maakte het echt gemakkelijk om honderden links bij te werken - JasonDavis


Ik heb https ingesteld, dan moet je het overal op de site gebruiken. U vermijdt het risico van problemen met gemengde inhoud en als u over de vereiste hulpmiddelen beschikt, kunt u de hele site beveiligen?

Met betrekking tot omleiding van http naar https is het antwoord niet zo eenvoudig.

Door omleiden wordt het voor uw gebruikers een stuk eenvoudiger, ze typen gewoon in whateversite.com en worden omgeleid naar https.

Maar. Wat als de gebruiker soms op een onveilig netwerk staat (of in de buurt is Troy Hunt en zijn ananas)? Dan zal de gebruiker vragen http://whateversite.com uit oude gewoonte. Dat is http. Dat kan in gevaar komen. De omleiding zou kunnen verwijzen naar https://whateversite.com.some.infrastructure.long.strange.url.hacker.org. Voor een gewone gebruiker zou het er heel legitiem uitzien. Maar het verkeer kan worden onderschept.

Dus we hebben hier twee concurrerende vereisten: gebruiksvriendelijk zijn en veilig zijn. Gelukkig is er een remedie genaamd de HSTS-header. Hiermee kunt u de omleiding inschakelen. De browser gaat over naar de beveiligde site, maar dankzij de HSTS-header onthoudt u deze ook. Wanneer de gebruiker intyptite.com op dat onbeveiligde netwerk typt, gaat de browser meteen naar https, zonder door de omleiding via http te springen. Tenzij u met zeer gevoelige gegevens omgaat, denk ik dat dit een eerlijke afweging is tussen beveiliging en bruikbaarheid voor de meeste sites. (Toen ik onlangs een aanvraag voor medische dossiers opstelde, ging ik alle https zonder omleiding). Helaas heeft Internet Explorer geen ondersteuning voor HSTS (bron), dus als uw doelgroep voornamelijk IE gebruikt en de gegevens gevoelig zijn, wilt u mogelijk omleidingen uitschakelen.

Dus als u geen IE-gebruikers target, maak dan gebruik van redirect, maar schakel ook de HSTS-header in.


38
2018-01-28 07:40



Meer mensen moeten hier ook op letten. Een ander ding is dat mensen aannemen dat ze veilig zijn omdat het eindpunt HTTPS is, waarbij het feit wordt genegeerd dat alle informatie die in GET's of POST's naar de pagina wordt verzonden, in platte tekst is. - Velox
@Velox - Ik denk niet dat de implicatie van "mensen aannemen dat ze veilig zijn omdat het eindpunt HTTPS is, en negeert het feit dat alle informatie die in GETs of POSTs naar de pagina wordt verzonden in platte tekst is" vrij nauwkeurig is. Hoewel er wat prullaria zijn, reizen GET-queryparameters niet tijdens het transport via HTTPS foutloos. Zie bijvoorbeeld: stackoverflow.com/questions/323200/... POST-payloads zijn ook beveiligd, maar zijn ook niet kwetsbaar voor logging- en verwijzende headers. - codingoutloud
@codingoutloud Dat is mijn punt. Over HTTPS zijn ze gecodeerd, maar in het eerste verzoek naar de HTTP-pagina waren ze dat niet. - Velox
@Velox - Als de hele site wordt omgeleid naar HTTPS, is het onwaarschijnlijk dat GET-parameters worden verzonden voordat HTTPS is gestart (en alles blijft HTTPS na dat punt). Er is nog steeds het eerste verzoek waar cookies worden verzonden, wat kan worden verholpen met HSTS ... en een klein aanvalsvenster voor SSLStrip, dat mogelijk door JavaScript kan worden verslagen, maar dat is een eigen wapenwedloop. - Brilliand
@Brilliand Eerlijk punt, maar een zwak punt in beveiliging maakt het hele ding zwak. Altijd het overwegen waard. - Velox


Er is niets mis mee, en in feite is het de beste methode (voor sites die moeten bediend via een beveiligde verbinding). In feite is wat je doet redelijk vergelijkbaar met de configuratie die ik gebruik:

<VirtualHost 10.2.3.40:80>
  ServerAdmin me@example.com
  ServerName secure.example.com
  RedirectMatch 301 (.*) https://secure.example.com$1
</VirtualHost>

# Insert 10.2.3.40:443 virtual host here :)

De 301 statuscode geeft a aan blijvend omleiden, opdracht geven aan capabele clients om de beveiligde URL te gebruiken voor toekomstige verbindingen (bijvoorbeeld de bladwijzer bijwerken).

Als u de site alleen via TLS / SSL gaat gebruiken, zou ik een andere richtlijn aanbevelen om HTTP in te schakelen Strikte transportbeveiliging (HSTS) in uw beveiligen virtuele host:

<IfModule mod_headers.c>
  Header set Strict-Transport-Security "max-age=1234; includeSubdomains"
</IfModule>

Deze header instrueert capabele clients (de meesten van deze dagen geloof ik) dat ze zouden moeten gebruik alleen HTTPS met het opgegeven domein (secure.example.comin dit geval) voor de volgende 1234 seconden. De ; includeSubdomains gedeelte is facultatief en geeft aan dat de richtlijn niet alleen van toepassing is op het huidige domein, maar ook daaronder (bijv. alpha.secure.example.com). Merk op dat de HSTS-kop is enkel en alleen geaccepteerd door browsers wanneer deze via een SSL / TLS-verbinding worden aangeboden!

Om uw serverconfiguratie te toetsen aan de huidige beste werkwijze, is een goede gratis bron SSL-servertest van Qualys service; Ik zou willen scoren op zijn minst een A- (je kunt niet meer krijgen dan dat met Apache 2.2 vanwege het gebrek aan ondersteuning voor elliptische curve-cryptografie).


22
2018-01-28 02:20



Ik zou moeten toevoegen, de kop sturen Strict-Transport-Security: max-age=0 zal elke eerdere richtlijn tenietdoen; zoals altijd, dit moet worden verzonden via HTTPS om te worden geaccepteerd, maar het is een handige manier om dingen te annuleren als u besluit dat u ook HTTP op het domein moet gebruiken. - Calrion


Wauw ! redirect HTTP naar HTTPS is een heel goede zaak en ik zie daar geen nadelen aan.

Zorg ervoor dat uw klanten over de juiste CA beschikken om niet-gebruikersvriendelijke waarschuwingen over het certificaat in de browser te voorkomen.

Bovendien lijkt de manier waarop je Apache hebt ingesteld om door te sturen naar HTTPS, goed.


5
2018-01-28 00:35





Is het slecht om http om te leiden naar https?

Nee helemaal niet. Eigenlijk is het goed om te doen!

Over omleidingen:

Het zou efficiënter kunnen zijn, door volledig elimineren van de rewrites. Hier is mijn config op een vergelijkbare situatie ...

<VirtualHost *:80>
  ServerName domainname.com

  <IfModule mod_alias.c>
    Redirect permanent / https://domainname.com/
  </IfModule>
</VirtualHost>

5
2018-01-28 13:45





HTTPS is niet echt waterdicht. Natuurlijk is het normaal een goede zaak om HTTPS te forceren. Het voorkomt dat normale criminelen iets slechts doen met uw gebruikers.

Maar vergeet niet om uw SSL-instellingen te controleren, zoals de SSLCiphers-instelling. Schakel dingen als RC4 crypto, het SSLv2- en SSLv3-protocol uit. Je zou ook moeten ontdekken of de crypto-systeem bibliotheken van je systeem TLS1.2 ondersteunen (wat je wilt hebben;))

Schakel SSL in, het is goed.


4
2018-01-28 07:43



Entropie raakt niet op (tenminste als je verdedigt tegen aanvallers op aarde liever dan voodoo doen). Of je begint met onvoldoende entropie en je kunt niets doen dat willekeur vereist, of je begint met voldoende entropie en je blijft voldoende entropie houden, ongeacht hoeveel willekeur je genereert. - Gilles
Sorry, wat? Er zijn een aantal bewerkingen op Linux die aandringen op van hardware afkomstige sterke entropie in plaats van op PRNG gebaseerde waarschijnlijk goed genoeg entropie, en die kunnen inderdaad blokkeren als de pooldiepte laag is. Het is zeer zeker mogelijk om met voldoende entropie op een Linux-systeem te beginnen, maar door overmatig gebruik om de pool leeg te laten lopen, waardoor sommige bewerkingen worden geblokkeerd. - MadHatter


Persoonlijk ben ik helemaal voor het gebruik van SSL om verbindingen op het web te beveiligen, maar ik heb het gevoel dat alle andere antwoorden hier hebben gemist, is dat niet elk apparaat en stuk software dat in staat is tot een HTTP-verbinding SSL kan gebruiken, dus zou ik overwegen om een ​​manier te bieden voor gebruikers om het te vermijden als het niet voor hen wordt ondersteund. Het is ook mogelijk dat mensen in sommige landen waar coderingstechnieken illegaal zijn, dan geen toegang hebben tot uw site. Ik zou overwegen om een ​​niet-versleutelde landingspagina toe te voegen met een link om de onveilige versie van de site te forceren, maar tenzij een gebruiker dit specifiek selecteert om te doen wat je zei en ze gewoon door te sturen naar de HTTPS-versie.


3
2018-01-28 10:13



Een probleem met oplossingen zoals het hebben van een eenvoudige HTTP-bestemmingspagina, zelfs als deze op de juiste manier is gescheiden, is dat deze pagina open staat voor manipulatie. Dat wil zeggen, er is geen echte garantie dat de link voor de HTTPS-versie van de site intact aan bezoekers wordt bezorgd. - Håkan Lindqvist