Presidentti Ronald Reagan pitää tiedotustilaisuuden terrori-iskun jälkeen Länsi-Berliinin diskossa

Yritän saada jonkinlaista ymmärrystä suojaamattomien (http: // käytettyjen) ja SSL-suojattujen (https: //) verkkosivustojen välillä Apache-palvelimilla. Joten en yritä ratkaista tiettyä ongelmaa juuri nyt, mutta saan jonkinlaista ymmärrystä, jotta voin ratkaista ne tulevaisuudessa. Se on jaettu isäntä, ja minulla on pääsy vain .htaccess-tiedostoon. Toivon, että joku voi pystyä neuvomaan. Pisteet ovat:

  1. Jos minulla on suojaamaton sivusto, jonka osoite on http://example.com/omakirjoitus.php, ja ostan sitten SSL-varmenteen, voinko silti käyttää sitä osoitteella http: // vai pitääkö sitä käyttää nyt https: n kautta : //?
  2. Onko oikein, että joku voi pakottaa pääsyn https: //: lla kirjoittamalla uudestaan ​​säännöt .htaccessista? Eli jos joku käyttää sitä kuten yllä, se voidaan tosiasiallisesti pakottaa olemaan https://example.com/myscript.php? Mitä siinä tapauksessa tapahtui asiakkaan lähettämälle alkuperäiselle http://example.com/myscript.php -pyynnölle - oliko se Internetissä ja avoinna hakkerointiin?
  3. Luulen olevani oikeassa sanoessani, että .htaccessin käyttäminen pakottaaksesi osoitteesta https: // tiedostoon http: // ei toimi, koska suojattu viestintä on määritetty ennen .htaccessin käyttöä?
  4. Jos PHP-komentosarjassa on uudelleenohjaus osoitteesta - sano myscript1.php - ./myscript2.php (ts. Toinen komentosarja samassa hakemistossa) ja sivusto on SSL-suojattu, pakottaako se pääsyn toiseen komentosarjaan suojattavaksi vai ei? Jos se ei, kuinka yksi pakottaa sen?

Toivottavasti hyödyllisiä vastauksia, kiitos.

  • Rajoita vain yksi kysymys viestiä kohti.

Sinulla on paljon kysymyksiä yhdessä postissa, ja mielestäni jotakin ydin väärinkäsitystä, joka saa sinut näkemään asioita outolla tavalla, joten toivon, että seuraava voisi auttaa sinua selvittämään näkemyksesi tai ainakin laukaisemaan joitain malmia koskevia selittäviä kysymyksiä.

Ensin haluaisin puhua terminologiasta:

  1. Lopeta SSL: n sanominen. Tiedän, että kaikki tekevät, mutta se on vain puhtaasti väärin. SSL on vanha protokolla, jota ei ole enää olemassa.Sen seuraaja on TLS, ja tätä kaikki verkkosivustot käyttävät juuri nyt, versioita on useita, ja uusimmasta, 1.3, pitäisi pian tulla standardi. Tähän liittyen lopeta SSL-varmenteen sanominen, koska se on kaksi kertaa virheellinen nimi. Se on X.509-varmenteen käyttö TLS-yhteydelle: voit käyttää X.509-varmenteita muihin asioihin (kuten sähköpostin salaukseen ja todennukseen S / MIME: n kautta) ja voit tehdä TLS-yhteyksiä ilman varmenteita.
  2. Älä lyö niin usein .htaccess koska se ei useimmiten liity esille nostamiinne kohtiin. Ensinnäkin tämä on ominaista yhdelle verkkopalvelimelle, nimittäin Apachelle, jossa voit käyttää mitä tahansa siellä olevaa verkkopalvelinta, sen kokoonpano muuttuu (muoto, syntaksisäännöt, nimi jne.), Mutta on siellä saman tavoitteen saavuttamiseksi. Toiseksi, koska jopa Apachen avulla voit määrittää sen "järjestelmän" kokoonpanotiedostoissa, kuten tiedostoissa /etc. Itse asiassa, kun voit, suosittelen sitä .htaccess sen käyttö on monimutkaisempaa (erityisesti uudelleenohjauksissa), ja sillä voi olla huonoja seurauksia turvallisuuteen ja suorituskykyyn.

Nyt tarkat kohdat.

Siirtyminen HTTP: stä HTTPS: ään

Jos minulla on suojaamaton sivusto, jonka osoite on http://example.com/omakirjoitus.php, ja ostan sitten SSL-varmenteen, voinko silti käyttää sitä osoitteella http: // vai pitääkö sitä käyttää nyt https: n kautta : //?

Tämä on puhtaasti henkilökohtainen valinta. Heti kun olet määrittänyt verkkosivustosi käytettäväksi HTTPS: n kautta, voit päättää sammuttaa pääsy siihen HTTP: n kautta tai saada palvelimesi ohjaamaan kaikki HTTP-yhteydet vastaaviin HTTPS: ssä. Tämä on sinun päätöksesi tehdä.

Huomaa kuitenkin, että on olemassa useita tekniikoita, jotka saattavat pakottaa selaimen siirtymään HTTPS: ään automaattisesti, jopa ilman HTTP-kokeilua. Katso esimerkiksi HTTP Strict Transport Security (HSTS) ja HSTS-esilataus (https://hstspreload.org/), joissa verkkosivustojen luettelo toimitetaan selainten kanssa varmistaakseen, että ne eivät koskaan palaa takaisin ("alenna") HTTP: ksi.

Myös tulevaisuudessa selaimet alkavat näyttää kaikki HTTP-verkkosivustot epävarmoina. Katso esimerkiksi: https://www.cnet.com/news/chrome-warning-insecure-http-websites-expose-passwords-credit-card-numbers/

Yhteenvetona voidaan todeta, että siirtyminen on todella kohti verkkoa, jossa olisi vain HTTPS. Siksi ei todennäköisesti ole järkevää pitää HTTP-versiota, kun otit HTTPS-version käyttöön. Mutta kaikki riippuu rajoituksistasi.

(PS: Kudot ovat käyttäneet example.com URL-osoitteessasi; tämä on oikea asia. Katso RFC2606, jos olet utelias)

Kirjoittaa uudestaan ​​HTTP: stä HTTPS: ään

Onko oikein, että joku voi pakottaa pääsyn https: //: lla kirjoittamalla uudestaan ​​säännöt .htaccessista? Eli jos joku käyttää sitä kuten yllä, se voidaan tosiasiallisesti pakottaa olemaan https://example.com/myscript.php? Mitä siinä tapauksessa tapahtui asiakkaan lähettämälle alkuperäiselle http://example.com/myscript.php -pyynnölle - oliko se Internetissä ja avoinna hakkerointiin?

Ensinnäkin pieni kiertotie HTTP-ydinominaisuuksista (jotka ovat myös HTTPS-ominaisuuksia, koska HTTPS on HTTP TLS: n kautta). HTTP-palvelimen vastaus kaikkiin pyyntöihin virhekoodilla, joillakin otsikoilla ja sisällöllä. Virhekoodi ilmoittaa asiakkaalle mitä tapahtuu. Jotkut virhekoodit luotiin uudelleenohjausominaisuuden selkeästi huomioon ottamiseksi, nämä ovat virhekoodit 301, 302, 307 ja 308 (täydelliset tiedot siellä: https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#3xx_Redirection). Näissä tapauksissa palvelin sisällyttää vastauksessaan otsikoihin uudelleenohjauksen kohteen URL-osoitteen ja asiakas lukee sen ja menee hakemaan sitä.

Tässä mielessä, jos asiakas aloittaa HTTP-pyynnön ja jos palvelin on määritetty vastaamaan siihen uudelleenohjauksella, palvelin vastaa uudelleen selkeästi (kuten HTTP-pyyntö) tarvittavalla virhekoodilla ja lopullisella URL-osoitteella , olkoon sen kanssa https:// tai http://. Asiakas aloittaa sitten uuden kyselyn tällä uudella URL-osoitteella.

Olet oikeassa, että alkuperäinen HTTP-pyyntö + vastaus on selkeä ja siten haavoittuva: joku kolmas osapuoli voi siepata ja kirjoittaa uudestaan ​​sekä pyynnön että vastauksen ja johtaa asiakkaan harhaan. Tämä on täsmälleen HSTS-esilatauksen tavoite: varmista, että asiakkaat alkavat suoraan HTTPS-kyselyillä.

Kirjoittaa uudestaan ​​HTTPS: stä HTTP: ksi

Luulen olevani oikeassa sanoessani, että .htaccessin käyttäminen pakottaaksesi osoitteesta https: // tiedostoon http: // ei toimi, koska suojattu viestintä on määritetty ennen .htaccessin käyttöä?

Uudelleenohjaus voidaan tehdä mistä tahansa URL-osoitteesta mihin tahansa toiseen, kunhan palvelin on määritetty oikein käsittelemään tätä riippumatta käyttämistäsi malleista (URL: n URL-osoitetta edeltävää osaa kutsutaan järjestelmäksi, joten verkolle se on http tai https).

Joten voit teknisesti ehdottomasti ohjata https: // ... URL-osoitteen http: // ... ... Tällä ei tietenkään ole juurikaan järkeä (menetät kaikki turvaominaisuudet, joita HTTPS: n TLS tarjosi sinulle) ja voi jopa olla nähdään hyökkäyksenä.

Nyt sekoitat useita asioita täällä ja keskityt .htaccess mikä on tässä merkityksetöntä. Yritetään muotoilla / tarkentaa mielipiteesi: https: // URL-osoitetta varten asiakas muodostaa TLS-yhteyden palvelimeen, jonka sisällä se lähettää pyyntönsä, joten periaatteessa pyydetty URL ja jotkut otsikot. Palvelin saa sen TLS-yhteydestä ja päättää vastauksensa sekä asiakkaan lähettämien tietojen että oman kokoonpanonsa perusteella (olipa se joissakin .htacess tiedosto tai muualla).

Kirjoitusten uudelleenkirjoittaminen

Jos PHP-komentosarjassa on uudelleenohjaus osoitteesta - sano myscript1.php - ./myscript2.php (ts. Toinen komentosarja samassa hakemistossa) ja sivusto on SSL-suojattu, pakottaako se pääsyn toiseen komentosarjaan suojattavaksi vai ei? Jos se ei, kuinka yksi pakottaa sen?

Ensinnäkin tärkeä ymmärrettävä asia: etänä asiakkaalla ei ole mitään tapaa tietää, mikä URL-osoite on, jos se vastaa palvelimella staattista resurssia, ohjataanko se uudelleen, välityspalvelin, hylätäänkö se vai käynnistetäänkö ohjelma vastauksen rakentamiseksi jne. Sama hierarkialle: URL-osoitteessa näkyvä ei välttämättä näy palvelimen levyllä. Esimerkiksi kaksi komentosarjaa, jotka näyttävät olevan samalla tasolla URL-vertailun perusteella, voivat myös olla täysin eri paikoissa verkkopalvelimessa.

Joten uudelleenohjaukset ja URL-osoitteet toimivat teknisesti samalla tavalla, jos niillä on image.png lopussa script.php. Muista myös, että "pidennys" (pisteen jälkeen) on puhtaasti käytäntö, image.png voi vastata JPEG-kuvaa (mutta typerä) ja olla joko staattinen tiedosto levyllä tai generoitu pyynnöstä ja sama kohteelle script.php se voi olla kuva.

Yritetään joka tapauksessa kuvata tapaustasi. Sinä hallitset www.server1.example ja sinulla on URL-osoite https://www.server1.example/myscript1.php. Sen URL-osoitteen kohdalla, johon haluat asiakkaiden ohjaavan uudelleen https://www.server2.example/myscrip2.php. Sinä hallitset palvelinta www.example1.com joten voit määrittää sen sallimaan tämän uudelleenohjauksen.

Näin tapahtuu:

  1. Asiakas muodostaa yhteyden www.server1.example avaamalla siihen TLS-yhteys ja pyytämällä sitten URL-osoitetta
  2. Palvelimen vastaus antaa uudelleenohjauksen virhekoodin, kuten 301 plus uusi URL-osoite
  3. Asiakas avaa sitten uuden yhteyden www.server2.example täysin erillinen, jälleen TLS: n kanssa ja pyytää uutta URL-osoitetta siellä.

Joten molemmat vaihdot ovat turvallisia, koska ne tehdään TLS: n kautta. Tämä on tietysti yleistys, yhteydet voivat olla erilaiset (mutta silti TLS: n kanssa), jos toisella URL-osoitteella olisi jälleen www.server1.example (ensimmäistä voidaan käyttää uudelleen, koska se on sama isäntänimi toisen pyynnön lähettämiseen), tai jos molemmat isäntänimet ratkaisevat saman IP-osoitteen tai uudemmilla protokollilla, kuten HTTP / 2, joka yrittää optimoida erilaisia ​​asioita.

Mutta periaatteessa URL-osoitteen sisältö ei määrää, onko yhteys suojattu vai ei, se on sen kaava, ja jos se on https, joka on http TLS: n kautta, pelkän http: n sijaan.

  • Todella hyödyllinen vastaus, kiitos. Syynä monipuolisiin kysymyksiin on, että yritän saada periaatteet selviksi eikä ratkaista tiettyä ongelmaa, joten voin myöhemmin ratkaista tiettyjä kysymyksiä. Vastauksesi auttoivat paljon.
  • Kokeilin sitä (2): lla .htaccess-uudelleenkirjoitussäännöillä, ja se ei toiminut (syynä yritykselle oli estää https-oletusarvoiset selaimet heittämästä suojaamattomia virhesivuja pääsemättä suojaamattomalle sivustolle ). Oletin, että syy oli se, että selain yritti määrittää suojatun tiedonsiirron palvelimen kanssa, epäonnistui niin, eikä koskaan päässyt niin pitkälle kuin mikään .htaccess uudelleenkirjoitussääntö.
  1. Kyllä, voit käyttää sivustoa http: n tai https: n kautta, mutta nykyaikaiset selaimet näyttävät varoituksen, jos sivusto ei käytä SSL: ää
  2. Joo. Koodi on RewriteCond %{SERVER_PORT} =80 RewriteCond %{HTTP_HOST} !^www\. [NC] RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

  3. Miksi haluat pakottaa http: n, kun sinulla on kelvollinen varmenne?

  4. Jos sinulla ei ole kohdassa 2 olevaa koodia paikallaan, se ohjaa samaan protokollaan kuin alkuperäinen sivu. Yllä olevan mallikoodin ollessa kuitenkin kaikki skriptit ovat https.

  • Kohdassa 3 yksinkertaisesti siksi, että yritän ymmärtää, miten se toimii ja mikä on mahdollista. Yritin joitain uudelleenkirjoitussääntöjä estääksesi pääsyn suojaamattomalle sivustolle https: //: lla heittämästä 'tämä suojaamaton sivusto' -virhesivua, eikä se toiminut.

työskennellyt sinulle: Charles Robertson | Haluatko yhteyttä?