Kysymys:
Miksi HTTPS ei ole oletusprotokolla?
blunders
2011-06-05 23:59:48 UTC
view on stackexchange narkive permalink

Miksi HTTP: tä käytetään edelleen yleisesti, sen sijaan uskon paljon turvallisemmaksi HTTPS: ksi?

Esimerkki: [Miksi sovellusten lataamista ei tehdä rutiininomaisesti HTTPS: n kautta?] (Http://security.stackexchange.com/q/18853)
Ei suoraan sidoksissa, mutta mielenkiintoinen otos Troy Huntilta: https://www.troyhunt.com/i-wanna-go-fast-https-massive-speed-advantage/ Pohjimmiltaan HTTP / 2 toimii vain TLS: n kanssa, joten HTTPS: n käyttövoi parantaa nopeutta (jos asiakas ja palvelin käyttävät HTTP / 2: ta).
IMO, selainten ei pitäisi hyväksyä osoitetta ilman järjestelmää ollenkaan.Jos haluat löytää tietoja verkkotunnuksesta tai IP-osoitteesta, tämä on tuskaa perseeseen Chromen ja muiden selainten kanssa, joilla ei ole erillistä hakukenttää.
Ratkaisua etsiville: [käytä laajennusta] (https://chrome.google.com/webstore/detail/smart-https/cmleijjdpceldbelpnpkddofmcmcaknm?hl=fi)
Yhdeksän vastused:
#1
+68
Thomas Pornin
2011-06-06 01:39:39 UTC
view on stackexchange narkive permalink

SSL / TLS: llä on pieni yleiskustannus. Kun Google vaihtoi Gmailin HTTPS: ään (valinnaisesta ominaisuudesta oletusasetukseen), he huomasivat, että suorittimen yleiskustannukset olivat noin + 1% ja verkon yleiskustannukset + 2%; katso lisätietoja tästä tekstistä. Tämä koskee kuitenkin Gmailia, joka koostuu yksityisistä, dynaamisista, jakamattomista tiedoista ja isännöi Googlen järjestelmissä, joihin pääsee kaikkialta hyvin viiveellä. HTTPS: n tärkeimmät vaikutukset verrattuna HTTP: hen ovat:

  • Yhteyden muodostaminen vaatii ylimääräisiä verkon edestakaisia ​​matkoja. Koska tällaiset yhteydet "pidetään hengissä" ja käytetään uudelleen aina kun mahdollista, tämä ylimääräinen viive on merkityksetön, kun tiettyä sivustoa käytetään toistuvassa vuorovaikutuksessa (kuten Gmailille tyypillistä); järjestelmät, jotka palvelevat enimmäkseen staattista sisältöä, saattavat löytää verkon yleiskustannuksista merkityksettömiä.

  • Välityspalvelimet eivät voi tallentaa välimuistiin HTTPS: llä palvelettuja sivuja (koska ne eivät edes näe kyseisiä sivuja). Tässäkin ei ole mitään staattista välimuistia Gmailin kanssa, mutta tämä on hyvin erityinen asiayhteys. Internet-palveluntarjoajat pitävät välimuistista erittäin kiinnostuneina, koska verkon kaistanleveys on heidän elämänsä.

  • HTTPS on HTTP SSL / TLS: ssä. TLS-kättelyn aikana palvelin näyttää varmenteensa, jonka on määritettävä tarkoitettu palvelimen nimi - ja tämä tapahtuu ennen itse HTTP-pyynnön lähettämistä palvelimelle. Tämä estää virtuaalisen isännöinnin, ellei käytetä TLS-laajennusta, joka tunnetaan nimellä Palvelimen nimen indikaatio. tämä edellyttää asiakkaan tukea. Erityisesti Internet Explorer ei tue palvelimen nimen osoittamista Windows XP: ssä (IE 7.0 ja uudemmat, mutta vain Vistassa ja Win7: ssä). Kun otetaan huomioon WinXP: tä käyttävien työpöytäjärjestelmien nykyinen markkinaosuus, ei voida olettaa, että "kaikki" tukevat palvelimen nimen ilmaisua. Sen sijaan HTTPS-palvelinten on käytettävä yhtä IP-osoitetta palvelimen nimeä kohti; IPv6-asennuksen nykyinen tila ja IPv4-osoitepula tekevät tästä ongelman.

  • HTTPS on "turvallisempi" kuin HTTP seuraavassa mielessä: tiedot todennetaan saapuviksi nimetyiltä palvelimilta ja siirto on luottamuksellista kenelle tahansa, joka saattaa kuunnella linjaa. Tämä on suojausmalli, jolla ei ole järkeä monissa tilanteissa: esimerkiksi kun katsot videota Youtubesta, et välitä siitä, tuleeko video todella youtube.com-sivustolta vai joltakin hakkereilta, jotka lähettävät (kohteliaasti) sinulle video, jonka haluat nähdä; ja video on joka tapauksessa julkista tietoa, joten luottamuksellisuus on tässä vain vähäistä. Todennus tehdään myös vain suhteessa palvelimen varmenteeseen, joka tulee sertifiointiviranomaiselta, jonka asiakasselain tietää. Sertifikaatit eivät ole ilmaisia, koska sertifikaattien tarkoitus on, että varmentaja todistaa varmenteen omistajan fyysisesti (en sano, että kaupallinen varmentaja hinnoittelee sertifikaattejaan oikeudenmukaisesti; mutta jopa Buddhan itsensä ylläpitämä oikeudenmukaisin CA on vielä perittävä maksu todistuksesta). Kaupallinen CA halusi vain rakastaa HTTPS: ää oletusarvona. Lisäksi ei ole selvää, tarvitaanko X.509-varmenteiden sisältämää PKI-mallia todella "oletusarvoisesti" koko Internetille (varsinkin kun on kyse varmenteiden ja DNS: n välisistä suhteista - jotkut väittävät, että Rekisteröijän tulisi antaa palvelinsertifikaatti verkkotunnuksen luomisen yhteydessä.

  • Monissa yritysverkoissa HTTPS tarkoittaa, että salakuuntelijat eivät näe tietoja ja että luokka sisältää kaikki erilaisia ​​sisältösuodattimia ja virustorjuntaohjelmistoja. HTTPS: n asettaminen oletukseksi tekisi monista järjestelmänvalvojista erittäin tyytymättömiä.

Kaikki nämä ovat syitä, miksi HTTPS ei välttämättä ole hyvä idea verkon oletusprotokollana. Ne eivät kuitenkaan ole syy siihen, miksi HTTPS ei ole tällä hetkellä verkon oletusprotokolla; HTTPS ei ole oletus yksinkertaisesti siksi, että HTTP oli siellä ensin.

Staattisen sisällön +1 saa osuman. Tarkastellaan sivustoa, jossa on useita -tageja. Koska jokaisella kuvalla on erillinen yhteys, esimerkiksi 2048-bittisen tai 4096-bittisen salatun yhteyden laskennallisesta yleiskustannuksesta voi tulla melko merkittävää mobiilialustoilla, joissa lisääntynyt suorittimen käyttö kuluttaa nopeasti akun, käyttäjät saattavat välttää sivustoasi, koska yhdestä syystä tai toisen heidän mielestään se tyhjentää heidän akunsa. Tämä on tietysti yksi ansio luottamuksellisen staattisen sisällön isännöimisestä erilliselle palvelimelle (ilman SSL: ää).
+1 @puddingfox: Mielenkiintoinen asia liittyen mobiililaitteiden suorittimen yleiskustannuksiin.
@puddingfox: Työskentelin aiemmin mobiilikehityksen pääministerinä, ja mielestäni, jos tietoturvaa tarvitaan, nykyinen suosikki on käyttää alustakohtaista natiivisovellusta, joka käyttää salattuja pakattuja tietoja vain REST / SOAP-sovellusliittymää puhuakseen verkkopalveluun. SSL-asennus käyttää fx 2048-bittistä (muista, että asennuksen jälkeen vaihdat fx 128-bittiseen AES: ään), mutta ** salauksen suorittimen kuormitus ei ole todellinen ongelma **. Todelliset ongelmat selaimen sisäisissä sovelluksissa / SSL: ssä ovat verkon viive ja viallinen Javascript-tuki mobiiliselaimissa. Siksi natiivisovellukset ovat edullisia.
"lievä" yläpuolella? Mielestäni ei. Latenssi on verkkopohjaisten sovellusten tappaja. Tätä pahentaa MSIE: n ssl-toteutuksen ongelmien historia (nyt pääosin ratkaistu). SSL: ään liittyy myös lisäkustannuksia (sertifikaatin ostaminen on vasta alkua).
@puddingfox:-selain avaa vain muutaman SSL-yhteyden tiettyyn sivustoon (esim. 3 tai 4) käyttämällä HTTP keep-hengessä lähettääksesi useita peräkkäisiä HTTP-pyyntöjä kussakin. Lisäksi vain ensimmäinen tarvitsee epäsymmetrisen avaimenvaihdon (se, johon liittyy noin 2048-bittinen avain); muut yhteydet käyttävät SSL / TLS "jatka istuntoa" -ominaisuutta (nopeampi kättely, vähemmän viestejä, vain symmetrinen salaus). Lopuksi, suurin osa SSL / TLS-palvelimista käyttää RSA-avainta ja RSA: n asiakasosa on halpa (palvelimelle aiheutuu suurin osa RSA: n kustannuksista).
`` Tämä on turvallisuusmalli, jolla ei ole järkeä monissa tilanteissa ... et todellakaan välitä ... '' - se on erittäin subjektiivista. Minä välitän.
Hyvä vastaus. On kuitenkin syy, miksi joku, joka on riittävän paranoidi, saattaa haluta katsoa youtube-videoita https: n kautta: niiden katselu https: n kautta tarkoittaisi, että salakuuntelija ei helposti pystyisi kokoamaan kirjaa katsomistasi videoista.
Väitteestä, jonka mukaan "et todellakaan välitä siitä, tuleeko video todella youtube.com-sivustolta", tämä on väärin. Jos katson videota, jossa Bruce Schneier puhuu salauksesta ja voin tehdä päätöksiä hänen mielipiteensä perusteella, haluan tietää, että viestiä ei ole muutettu kuljetuksen aikana.
@dotancohen: on eheys, joka on erillinen asia ja joka voidaan ratkaista ilman salausta. Videovirran digitaalinen allekirjoitus riittää osoittamaan, että videota ei muuteta sen lähteestä. Valitettavasti välimuistiin tallennettavan, salaamattoman sisällön digitaalista allekirjoittamista ei käytetä laajalti, koska sille ei ole laajalti käytössä olevaa infrastruktuuria, AFAICT.
@LieRyan: Kiitos, ymmärrän mitä tarkoitat. Siellä on vielä yksi este: videovirrat ovat välimuistissa olevia, salaamattomia _streaming_-sisältöjä, joten SHA1-hajautusta sisällöstä ei voida antaa. Ehkä IPSec voisi olla vastaus.
@dotancohen:: n yksityiskohdat vaihtelevat, mutta mitä suurin osa videoiden suoratoistotekniikasta on, on pilkkoa video pieniksi paloiksi. Nämä palat voidaan allekirjoittaa erikseen. Välimuistin on jo ymmärrettävä, kuinka virta on lohkottu, jotta streamit voidaan välimuistiin joka tapauksessa, joten puolet työstä on jo olemassa. On myös joitain virtajärjestelmiä, jotka käyttävät HTTP Range Request -tukea chunkingiin, joka on jo yleisesti ymmärretty tavallisessa HTTP-välimuistissa ja välityspalvelimessa.
On myös monia muita erittäin välimuistiin tallennettavia sisältöjä, jotka voivat hyötyä digitaalisesta allekirjoituksesta lisäämällä eheyttä ja todennusta ilman, että tarvitsevat välttämättä luottamuksellisuutta ja jolla ei ole ongelmaa, että sinun on oltava etsittävä suoratoisto, kuten videot. Olisi todella hyvä, jos HTTP: ssä on standardoitu mekanismi digitaalisten allekirjoitusten lisäämiseksi, jotka selaimet voivat tarkistaa eheyden varmistamiseksi ja jotka mahdollistavat välimuistivälimuistin allekirjoittaman sisällön välimuistissa. Tämä on vaihtoehto keskellä HTTPS: ää ja HTTP: tä.
http://www.httpvshttps.com/
"Kun otetaan huomioon WinXP: tä käyttävien työpöytäjärjestelmien nykyinen markkinaosuus", Windows XP: tä ei ole tuettu, ja voimme olettaa, että asiakasta kohdellaan nollapäivän hyökkäyksellä, joka estää asiakasta kykenemästä säilyttämään minkäänlaista luottamuksellisuutta. Joten miten tämä voitaisiin kirjoittaa uudelleen?
"Jopa kauneimman CA: n, jota Buddha itse ylläpitää, olisi silti perittävä maksu sertifikaatista" StartSSL ei peri maksua yksittäisestä TLS-varmenteesta. Ei myöskään salata.
@tepples,: llä ei ole merkitystä verkkosivustojen ylläpitäjille niinkään, tukeeko Windows XP: tä vai ei. Sen sijaan he välittävät siitä, kuinka moni käyttäjä ei voi käyttää verkkosivustoasi, jos otat SNI: n käyttöön (esim. Windows XP: n markkinaosuus). Tämä on kehittynyt ajan myötä. Monet sivustot ovat valmiita sulkemaan IE: tä käyttävät Win XP -käyttäjät, mutta eivät kaikki - ja on joitain markkinasegmenttejä, joissa ei-triviaali osa käyttäjistä käyttää IE: tä Win XP: ssä. Joten tämä ei ole mustavalkoinen asia - sivuston ylläpitäjien on tehtävä arviointipyyntö - ja Thomasin huomautukset ovat edelleen hyödyllisiä ja suurelta osin päteviä.
_Inertia_ on paljon vahvempi voima kuin mikään muu laskentateollisuudessa. Taistelen sitä vastaan ​​päivittäin.
[Entä tarkkuus?] (Http://goo.gl/Inw9GL) Siirry YouTube-videoon, mutta se antaa sinulle sisältöä Facebookista. Menet Facebookiin ja se näyttää sinulle Googlen sijaan. Menet Googleen ja se näyttää sinulle jotain, joka ei ole turvallista elämääsi. Tai tavaraa, joka voi viedä sinut vankilaan. Kuten ... virusten lataaminen tai nollapäivän hyväksikäyttö, joka käyttää tietokonettasi laittomien tavaroiden jakamiseen, valtioiden vastaisten puheiden lähettämiseen (vakava tai vakava rikos useammassa kuin useammassa maassa), salauksen viemiseen tai valtion salaisuuksien julkaisemiseen * mitä tahansa *. ** Kaikki tarvitsevat HTTPS: n **, he eivät vain tiedä sitä vielä.
@Thomas, Johtopäätös * "HTTPS ei ole oletus yksinkertaisesti siksi, että HTTP oli siellä ensin" * ei ole ollenkaan vakuuttava. Niin monet asiat ovat muuttuneet * sen jälkeen *, eikä HTTPS: n oletusarvoilla ole vastaavia ongelmia. Mielestäni ** syy on nopeus ja nopeus yksin **. Joko se, tai [tilavalvonta] (https://goo.gl/h5eDpz). Jos oletamme (kuten johtopäätöksesi väittää), että nopeus ja viive eivät olleet ** syy **, niin Chrome voisi varmasti noutaa ensin HTTPS-sivun ja palata takaisin HTTP: hen, kun yhteyden aikakatkaisu? (SNI ei myöskään ole ongelma, kuten Chromella on.)
@Pacerier putoaminen on paikka, jossa se epäonnistuu kokonaan.Ajattele MitM-hyökkäyksiä.MitM saattaa vain estää pääsyn portin 443 kautta, ja kun älykromisi putoaa takaisin tekstinkäsittelyyn, he saavat tietosi.
#2
+32
Jesper M
2011-06-06 02:46:01 UTC
view on stackexchange narkive permalink

Vaikka hyviä vastauksia on jo annettu, uskon, että yksi näkökohta on toistaiseksi unohdettu.

Tässä se on: Tavallinen HTTP on verkon oletusprotokolla, koska suurin osa verkko ei tarvitse suojausta.

En halua vähätellä kysymystä tai joidenkin verkkosivustojen / sovellusten turvallisuusongelmia. Mutta voimme toisinaan unohtaa, kuinka paljon verkkoliikennettä:

  • sisältää vain täysin julkista tietoa
  • tai sillä on vain vähän tai ei lainkaan arvoa
  • tai missä on enemmän kävijöiden nähdään kasvattavan sivuston arvoa (uutismedia, verkostovaikutus -sivustot)

Muutama nopea esimerkki, olen varma, että voit tehdä nopeasti enemmän mielessäsi:

  • Lähes kaikki yritysten verkkosivustot, joita kutsutaan joskus "esitteiden ohjesivustoiksi", joissa luetellaan julkista tietoa yrityksestä.
  • Lähes kaikki uutiset, blogit , TV-asemat jne., Jotka ovat valinneet mainostuen ensisijaiseksi kaupallistamisstrategiakseen.
  • Palvelut, jotka saattavat tarjota sisäänkirjautumisia ja muita personointeja, mutta jotka myös luovuttavat sisällön kenellekään selaa nimettömästi (YouTube fx).
Olen samaa mieltä, ei ole mitään syytä jättää mitään huomiotta. Yksi asia, jota olen miettinyt, ja liittyy julkisen tiedon asiaan. Onko URL-osoitteet, joita tarkastellaan HTTPS-tapahtumien aikana yhdelle tai useammalle verkkosivustolle yhdestä IP-osoitteesta, erotettavissa? Oletetaan esimerkiksi, että HTTPS-URL-osoitteet kahdelle verkkosivustolle yhdellä IP-osoitteella 5 minuutin aikana: "A.com/1", "A.com/2", "A.com/3", "B.com/1" "B.com/2"; paljastaisi mitään paketteja, paljastaisi vain IP: n, joka oli käynyt sivustoissa "A.com" ja "B.com", paljastaisi täydellisen luettelon kaikista käydyistä HTTPS URL-osoitteista, paljastaisiko vain "A.com": n ja "B.com": n IP , tai jotain muuta?
@blunders:-kommentit eivät ole parhaita paikkoja kysyä uusia kysymyksiä. Katso seuraava linkki tai avaa uusi kysymys. http://security.stackexchange.com/questions/2914/can-my-company-see-what-https-sites-i-went-to
+1 @Jesper Mortensen: Kiitos, samaa mieltä. Tarkasti toisen kysymyksen ja lähetti tämän kysymyksen: [Onko URL-osoitteet, joita HTTPS-tapahtumien aikana katsotaan yhdelle tai useammalle verkkosivustolle yhdestä IP-osoitteesta, erotettavissa?] (Http://security.stackexchange.com/questions/4388/are-urls-viewed- https-tapahtumien aikana yhdelle tai useammalle verkkosivustolle yksittäisestä i: stä)
Puhelinnumero "esitteiden sivustolla" saattaa olla täysin julkista tietoa. Tämä ei tarkoita, että puhelinnumeron väärentäminen tällä verkkosivustolla ei ole turvallisuusriski.
@JesperMortensen, Olet hämmentynyt "ei tarvitse turvallisuutta" ja "ei tarvitse yksityisyyttä". Kyllä, tiedot ovat julkisia, se ei tarkoita, että voimme välttää HTTPS: n (mitm voi yksinkertaisesti palauttaa harhaanjohtavan sivun).
@JesperMortensen, Mitä koskee * "Lähes kaikki yrityssivustot, joita joskus kutsutaan esitteiden sivustoiksi, joissa luetellaan julkisia tietoja yrityksestä" *, ja ilman HTTP: tä hakkeri voi kaapata kyseisen sivun ja lisätä siihen mitä haluaa. Onko se hyväksyttävää?
@JesperMortensen, Ok Tajusin, että tämä kolmas kommentti on muutama kuukausi myöhässä, mutta tämä on tärkeää: ** HTTPS ei koske pelkästään turvallisuutta. ** Kyse on myös tarkkuudesta. Sanoit, että verkko ei tarvitse suojausta, mutta onko verkko tarkkuutta? (Kuvittele vain [kuinka paljon sekasortoa] (http://security.stackexchange.com/questions/4369/why-is-https-not-the-default-protocol#comment200128_4376) voisi olla, kun vierailemme osoitteessa "a.com". mutta hae sisältöä osoitteesta "b.com" ja päinvastoin. Siirry osoitteeseen "youtube.com" odottaen nähdäksesi joitain videoita, mutta se ohjaa sinut osoitteeseen "bing.com".)
#3
+6
Mike Scott
2011-06-06 00:15:45 UTC
view on stackexchange narkive permalink
  • Se lisää huomattavasti enemmän suorittimen kuormitusta palvelimelle, erityisesti staticcontentille.
  • Pakettikaappeilla on vaikeampaa virheenkorjausta
  • Se ei tue nimipohjaisia ​​virtuaalipalvelimia
+2 @D.W .: Arvaa, että on järkevää, että olisi vaikea saada universaalia tapaa jakaa sovelluskohtaisia ​​toteutuksia; mikä tarkoittaa, että et voi vain tehdä kopiota avaimista ja määrityksistä debuggeriin sisäänrakennetun salauksen purkamiseksi. Ja kyllä, olin nähnyt sen luetellun @Thomas-vastauksessa, joka lähetettiin @Mike Scottin jälkeen; jätin sen sellaisenaan, koska mietin, onko @Mike Scottilla toinen syy. Kippis!
@D.W. Myöskään Windows XP: tä ei tueta. Sen tuen päättyminen huhtikuussa 2014 rikkoo viimeisen merkittävän esteen SNI: n käyttöönotolle.
@tepples, kommenttini on kirjoitettu 4 vuotta sitten. Ilmeisesti Windows XP: n tilanne on kehittynyt ajan myötä. (Ja sillä ei ole merkitystä, tuetaanko Windows XP: tä vai ei. Tärkeää on, kuinka monta käyttäjää käyttää Windows XP: tä - ts. Kuinka moni käyttäjä ei voi käyttää verkkosivustoasi, jos otat SNI: n käyttöön. Kuten kirjoitin kommentti, katso Thomas Porninin vastaus.)
@D.W. Huomautin, että kommenttisi oli sittemmin vanhentunut. Pahoittelen, että en ole selventänyt asiaa. Mutta vaikka sinulla olisi paljon XP-käyttäjiä, mikä on järkevää muodostaa suojattu yhteys koneeseen, joka itse todennäköisesti vaarantuu nollapäivällä?
@tepples, se ei ole niin yksinkertaista. Mikä on kyseisen käyttäjän arvo sivuston omistajalle? Vastaus riippuu sivustosta. He eivät menetä kyseistä käyttäjää ja saattavat pystyä kaupallistamaan kyseisen käyttäjän (esim. Käyttäjä saattaa haluta ostaa jotain heiltä, ​​joten he saattavat menettää myynnin, jos estävät tällaisia ​​käyttäjiä). Olen suurelta osin myötätuntoinen väitteellesi, mutta jälleen kerran sanon, että tämä ei ole niin leikattua ja kuivaa kuin yrität tehdä siitä. Jos haluat suostutella muita, on tärkeää ymmärtää näkökohdat, jotka ohjaavat heidän päätöksitään.
@tepples Se, että XP on tuen lopussa, ei tarkoita sitä, että sitä ei käytetä laajalti. Se ei ole vastauksen alku; XP-käyttäjien on edelleen ostettava tavaraa, joten he tarvitsevat edelleen SSL: ää, mikä tarkoittaa, että SNI ei ole hyvä ratkaisu.
@D.W. Olen avannut [toisen kysymyksen näistä näkökohdista] (http://security.stackexchange.com/questions/82066/can-serving-https-to-internet-explorer-on-windows-xp-be-made-secure).
#4
+6
Rory Alsop
2011-06-06 00:33:32 UTC
view on stackexchange narkive permalink

Http oli aina oletusarvo. Alun perin https: ää ei tarvittu mihinkään, se oli melkein lisäys, johon tartuttiin, koska kävi selväksi, että tietyissä olosuhteissa tarvittiin tietoturvaa.

Jopa nyt on niin paljon verkkosivustoja, jotka eivät tarvitse https: ää, että se ei ole vieläkään vakuuttava argumentti korvata http kokonaan.

Kun yhä tehokkaampia mekanismeja TLS-suojattujen yhteyksien ajamiseksi on, CPU: n yleiskustannuksista on tulossa paljon vähemmän ongelma.

#5
+6
Dog eat cat world
2011-08-23 02:10:32 UTC
view on stackexchange narkive permalink

Kukaan ei ole tuonut esiin selkeää ongelmaa, joka johtuu http: n käyttämisestä oletusarvona https: n sijaan.

Tuskin kukaan viittaa kirjoittamaan koko uri-koodin pyytäessään resurssia, joka on salattava ja / tai allekirjoitettu eri tarkoituksiin.

Otetaan esimerkkinä gmail, kun käyttäjät vierailevat osoitteessa gmail.com , he itse asiassa käyttävät http: n oletusprotokollaa https: n sijaan. Tässä vaiheessa turvallisuus on epäonnistunut tilanteissa, joissa vastustaja sieppaa liikenteen. Miksi? Koska html on mahdollista poistaa https-pyynnöstä ja osoittaa ne osoitteeseen http.

Jos https olisi itse asiassa oletusprotokolla, istuntosi verkkosivustoille olisi suojattu.

kysymys miksi http valitaan https: n sijaan, yllä olevat vastaukset ovat voimassa. Maailma ei ole vielä valmis salauksen laajaan käyttöön.

Kuvailet "SSL strippaus" -hyökkäystä. Selaimet ovat sittemmin toteuttaneet HTTP Strict Transport Securityn (HSTS) vastatoimenpiteenä, mukaan lukien HSTS-esilatausluettelot ja HTTPS Everywhere (lähinnä kolmannen osapuolen HSTS-esilatausluettelo).
@tepples HSTS on huonompi kuin hyödytön, koska se voidaan myös riisua tarjoamalla palvelinten omistajien väärä turvallisuuden tunne.
@Alice, Mitä tarkoitat HSTS voidaan irrottaa?
@Dogeatcatworld, Kysymys on ** miksi ** selaimet muuttavat käyttäjän pyynnön (kirjoittamalla URL-osoitteen) osoitteesta "web.com" muotoon "http: // web.com" eikä "https: // web.com"?
@Pacerier Ensimmäistä kertaa, kun käyttäjä seuraa linkkiä `` https: `'-mallin avulla sivustoon, joka käyttää HSTS: ää, joka ei ole esilatausluettelossa, HTTP-välityspalvelin, joka kirjoittaa uudestaan ​​kaikki linkit, voi kirjoittaa linkin uudelleen käyttämään` `http:' '-mallia. Siksi esilatausluettelo on olemassa, mutta mikään esilatausluettelo ei ole tyhjentävä. Niin kauan kuin käyttäjä pysyy valtakirjojen poistamisen takana, vierailee vain sellaisissa sivustoissa, jotka eivät ole selaimen esilatausluettelossa, ei koskaan avaa manuaalisesti `` https: `'-järjestelmää, eikä koskaan huomaa lukituskuvakkeen puuttumista oikeasta paikasta, käyttäjä ei ole tietoinen kaikki hyökkäykset.
#6
+3
thomasrutter
2014-09-09 05:41:11 UTC
view on stackexchange narkive permalink

Muiden jo esittämien syiden lisäksi:

  • Tarvitaan lisätyötä HTTPS: n määrittämiseksi palvelimelle

    Palvelimen järjestelmänvalvojan on määritettävä varmenteet kullekin toimialueelle. Tämä edellyttää vuorovaikutusta varmenteen myöntäjän kanssa todistamaan, että olet verkkotunnuksen todellinen omistaja ja hankit varmenteen uusimisen. Tämä voi tarkoittaa varmenteen allekirjoituspyyntöjen luomista manuaalisesti ja uusintojen ostamista tai automaattisen prosessin asettamista (kuten certbot Let's Encrypt -toiminnon avulla). Kummassakin tapauksessa se on enemmän työtä kuin HTTPS: n käyttämättä jättäminen.

  • Tarvitaan lisää IP-osoitteita

    Tämä ei todellakaan ole ongelma koska SNI (Server Name Identification) -tuki yleistyi selaimissa ja SSL-asiakaskirjastoissa.

    Perinteisesti oli kuitenkin tarpeen käyttää eri IP-osoitetta kullekin erilliselle sivustolle, joka käyttää SSL: ää tietyllä palvelimella ja portilla. Tähän vaikutti kyky tehdä nimipohjainen isännöinti (virtuaalinen isännöinti) - laajalti käytetty käytäntö, jonka avulla monia eri verkkotunnuksia voidaan isännöidä samasta IP-osoitteesta. HTTPS: n kanssa tavallinen nimipohjainen isännöinti ei toimi, koska palvelimen on tiedettävä, mikä isäntänimi on esitettävä SSL / TLS-vahvistuskerroksessa ennen HTTP-pyyntöä, joka sisältää isäntänimi, voidaan purkaa.

    Palvelimen nimen tunnistaminen (SNI), joka toteuttaa nimipohjaisen isännöinnin SSL / TLS-kerroksessa, poistaa tämän rajoituksen.

  • Hidas muutosnopeus

    HTTPS oli muutos olemassa olevaan HTTP-protokollaan, joka oli jo vakiintunut jo ennen kuin monet ihmiset alkoivat ajatella tietoturvasta. Kun tekniikka on vakiintunut ja yhtä läsnä kuin HTTP oli, voi kestää hyvin kauan, ennen kuin maailma siirtyy seuraajalleen, vaikka muutoksen syyt olisivatkin pakottavia.

Hei fjw - tämä on hyvin vanha kysymys, hyvät vastaukset ja hyväksytty vastaus. Vastauksesi ei tuo mitään uutta - kannustan sinua osallistumaan vastaamalla uusiin kysymyksiin.
Laaditko tämän todella heikkolaatuisena vastauksena? Olen todella pahoillani, törmäsin tähän, kun tutkin jotain ja tunsin, että nykyisissä vastauksissa ei käsitelty mielestäni joitain tärkeitä seikkoja. Olen täysin eri mieltä siitä, että tämä on "heikkolaatuinen vastaus".
Yhteisön jäsenet ilmoittivat sen minulle, ja olen heidän kanssaan samaa mieltä. Yllä oleva kommenttini selittää mielipiteeni.
#7
+2
Simon East
2014-04-13 09:14:24 UTC
view on stackexchange narkive permalink

Thomas on jo kirjoittanut erinomaisen vastauksen, mutta ajattelin tarjota vielä pari syytä, miksi HTTPS: ää ei käytetä laajemmin ...

  • Ei tarvita . Kuten Jesperin vastauksessa oivaltavasti huomautetaan, "suurin osa verkkotiedoista ei tarvitse suojausta". Kuitenkin hakukoneiden, mainosyritysten, maakohtaisten internet-suodattimien ja muiden "Big Brother" -ohjelmien (esim. NSA) seurannan lisääntyessä; se lisää tarvetta lisätä yksityisyyden suojaa.

  • Nopeus. Se tuntuu usein hidalta ylimääräisten edestakaisten lentojen takia. ja ylimääräiset varmenteiden peruutusluettelopyynnöt ( OCSP jne.). Onneksi SPDY (Googlen luoma ja nyt tuettu kaikissa suurimmissa selaimissa) ja jotkut mielenkiintoiset CloudFlaren työt auttavat siirtämään tätä.

  • Sertifikaattien hinta. Useimmat sertifikaatin myöntäjät veloittavat todistuksesta kohtuuttomia summia (satoja dollareita). Onneksi on ilmaisia ​​vaihtoehtoja, mutta nämä eivät saa niin paljon julkisuutta (etkö tiedä miksi?).

  • IP-osoitteiden hinta . Kunnes IPv6: n yleistyminen on yleistä, verkkosivustot kohtaavat kasvavan IPv4-osoitteiden niukkuuden (ja siten myös kustannusten). SNI mahdollistaa useiden varmenteiden käyttämisen yhdellä IP-osoitteella, mutta ilman SNI-tukea Windows XP: ssä tai IE 6: ssa, useimmat sivustot tarvitsevat edelleen erillisen IP-osoitteen SSL: n tarjoamiseksi.

  • Palvelimen suorittimen käytön lisääntyminen. Tämä on yleinen käsitys, mutta Googlen mukaan SSL / TLS ei ole enää laskennallisesti kallista ".

Myös taaksepäin yhteensopivuuden puute.
Viikko tämän vastauksen lähettämisen jälkeen Windows XP: tä ei enää tuettu. Mitä tämä muuttaa?
@tepples ei mitään, koska näitä ihmisiä ei päivitetty automaattisesti Windows 7: ksi.
[StartSSL on nyt saanut jonkin verran julkisuutta] (http://arstechnica.com/security/2016/09/firefox-ready-to-block-certificate-authority-that-threatened-web-security/), mutta ei tapaa, jolla oletettavastihalusi :-)
Minun on sanottava, että olen kiihkeästi eri mieltä väitteestä, jonka mukaan TLS ei ole laskennallisesti kallis.Siinä oletetaan, että kaikki sivustot palvelevat tehokkaasta laitteistosta.Tämä ei yksinkertaisesti ole totta, kun verkkopalvelin sattuu olemaan käynnissä sulautetussa laitteessa, jossa virrankäyttö on ensisijainen näkökohta.
#8
+1
blfoleyus
2014-12-30 03:18:13 UTC
view on stackexchange narkive permalink

Yksinkertaisin ja järkevin selitys kollegojeni keskuudessa on, että se on aina tehty HTTP: llä, miksi muuttaa sitä nyt.

Jos se ei ole rikki, älä korjaa sitä.

HTTP: n yksityisyys on aina ollut rikki.
iOS 9 rikkoo sen.Oletusarvoisesti ei http: ää muille kuin selainohjelmille.Eikä oletusarvoisesti vanhentuneita https-toteutuksia.
#9
+1
Rob
2016-07-11 10:09:21 UTC
view on stackexchange narkive permalink

Todellinen vastaus on, että SSL-varmenteita nykyisessä muodossaan on koomisen vaikea käyttää. Ne ovat niin käyttökelvottomia, että se uhkaa varmenteiden turvallisuutta, koska ihmiset käyttävät pikakuvakkeita vain saadakseen aikaan asioita. Sanon tämän joku, joka rutiininomaisesti käsittelee kaksisuuntaista SSL: tä (PKI-sertifikaatit), teknisten ominaisuuksien monimutkaisuuden aiheuttamia TLS-pinon yhteensopimattomuuksia ja kokoonpanojen (salausrajoitukset, vaihtoehdot, kielikohtaiset kirjastovirheet) hullua määrää , jne.), joita kutsutaan "TLSiksi".

Katso LetsEncryptin nousu todisteena siitä, että tämä on totta.

Caddy on käänteinen välityspalvelinprojekti, joka käyttää LetsEncryptia. Se voi uusia sertifikaatteja palvelimen ollessa käynnissä, ja ihmiset käyttävät todella lyhyitä vanhentumisia, koska uusimiset ovat automaattisia.



Tämä Q & A käännettiin automaattisesti englanniksi.Alkuperäinen sisältö on saatavilla stackexchange-palvelussa, jota kiitämme cc by-sa 3.0-lisenssistä, jolla sitä jaetaan.
Loading...