Hypertext Transfer Protocol Secure

HTTPS (suojattu Hypertext Transfer Protocol)
Perhe: Internet -protokollaperhe
Toiminta -alue: salattu tiedonsiirto
Portti: 443 / TCP
HTTPS TCP / IP -protokollapinossa :
käyttää HTTP
kuljetus SSL / TLS
TCP
Internet IP ( IPv4 , IPv6 )
Verkon käyttö Ethernet Token
-bussi 		Token
ring 		FDDI ...
Standardit: RFC 2818 (HTTP TLS: n kautta, 2000)

Hypertext Transfer Protocol Secure ( HTTPS , Englanti for "turvallisen hypertekstinsiirtoyhteyskäytäntö ") on tiedonsiirtoprotokolla on World Wide Web , jolla dataa voidaan siirtää turvallisesti salakuuntelulta. Se edustaa kuljetuksen salausta.

HTTPS: n kehitti Netscape ja se julkaistiin ensimmäisen kerran yhdessä SSL 1.0: n kanssa vuonna 1994 selaimensa kanssa.

Teknisesti se määriteltiin URI -malliksi , joka on lisäkerros HTTP: n ja TCP: n välillä .

Käyttää

HTTPS -protokollaa käytetään luottamuksellisuuden ja eheyden varmistamiseen WWW -palvelimen ja selaimen ( asiakkaan ) välisessä viestinnässä World Wide Webissä . Tämä saavutetaan muun muassa salauksella ja todentamisella .

Ilman salausta Internetin välittämät tiedot voivat lukea pelkkänä tekstinä kaikki, joilla on pääsy kyseiseen verkkoon . Avoimien (eli salaamattomien) WLAN -verkkojen leviämisen myötä HTTPS: n merkitys kasvaa, koska se mahdollistaa sisällön salaamisen verkosta riippumatta.

Todentamisella varmistetaan, että yhteyden molemmat puolet voivat tarkistaa yhteyskumppanin henkilöllisyyden, kun yhteys muodostetaan. Tällä estetään miespuoliset hyökkäykset ja joissakin tapauksissa myös tietojenkalastelu .

tekniikkaa

Syntaktisesti HTTPS on identtinen HTTP -järjestelmän kanssa, tietojen lisäsalaus suoritetaan SSL / TLS -protokollalla: SSL -kättelyprotokollaa käyttämällä viestintäkumppaneiden suojattu tunnistus ja todennus tapahtuu ensin. Yhteinen symmetrinen istuntoavain sitten vaihdetaan avulla epäsymmetristä salausta tai Diffie-Hellman-avaimen vaihto. Tätä käytetään sitten käyttäjätietojen salaamiseen .

Standardi portti HTTPS-yhteyksissä on 443.

Palvelinvarmenteiden lisäksi voidaan luoda X.509 .3: n mukaisia ​​allekirjoitettuja asiakasvarmenteita . Tämä mahdollistaa asiakkaiden todentamisen palvelimelle, mutta sitä käytetään harvoin.

Vanhempi HTTPS - protokollaversio oli S-HTTP .

Asiakkaan käsittely

Kun Netscape kehitti HTTPS: n, protokolla ja käyttäjäpuolen asiakasohjelmisto integroitiin web-selaimiin varhaisessa vaiheessa. Tämä tarkoittaa, että erillisen ohjelmiston lisäasennusta ei yleensä tarvita.

SSL -symboli.png

HTTPS -yhteys valitaan https -URL -osoitteen avulla ja osoitetaan SSL -logolla. Tämä näkyy kaikissa yleisimmissä selaimissa pienenä lukkosymbolina osoiterivillä.

Vaihtoehdot HTTPS -valikoimasta

Päätös siitä, käytetäänkö suojattua HTTPS -yhteyttä HTTP -yhteyden sijasta, voidaan tehdä eri tavoin:

  • Palvelinpuolella vain HTTPS on sallittu, kuten yleensä verkkopankissa ; Joskus valittu http -osoite välitetään automaattisesti https -osoitteeseen.
  • Kirjautuminen pakotetaan HTTPS: n kautta, sitten selaimeen asetetaan HTTP -eväste ja laskenta -ajan säästämiseksi lisäpalvelu käsitellään salaamattomana; z. B. eBayssa .
  • Asiakaspuoli HSTS : n kautta : Jos palvelin sallii vain HTTPS: n (kuten edellä on kuvattu), selain voi tallentaa tämän ja muodostaa aina yhteyden HTTPS: n kautta tulevaisuudessa. Jos palvelin on myös HSTS -esilatausluettelossa, selain muodostaa HTTPS -yhteyden suoraan ensimmäisellä käynnillä.
  • Client-side tuloa HTTPS variantin tai selaimen plug-in (esim Firefox ja Chrome " HTTPS Everywhere "), joka korvaa http pyynnöt https palvelupyynnöt, jotka tukevat sekä variantteja.
  • Vuodesta 2020 (versio 83) Firefox voidaan asettaa käyttämään vain HTTPS -protokollaa. Jos verkkosivustoon pääsee vain suojaamattoman HTTP: n kautta, pääsy tapahtuu vain käyttäjän nimenomaisella suostumuksella.

Alkuperäisen rakenteen mukaan asiakasselaimen pitäisi ensin näyttää varmenne käyttäjälle HTTPS -osoitteen valitsemisen jälkeen . Hän päättää nyt, luottaako se tämän istunnon varmenteeseen ja mahdollisesti myös tallentaa sen pysyvästi, tarvittaessa tarkistettuaan sen määritettyjen linkkien kautta. Muussa tapauksessa HTTPS -yhteyttä ei muodosteta ("Jätä tämä sivu" Firefoxissa tai "Napsauta tätä poistuaksesi tästä sivusta" Internet Explorerissa).

Esiasennetut varmenteet

Tämän kyselyn välttämiseksi, joka saattaa olla ärsyttävää tuntemattomille, selaimen valmistajat ovat ajan myötä hyväksyneet useita juurivarmenteita, jotka on jo syötetty asennuksen aikana. Verkkosivustot, joilla on vastaavat varmenteet, sekä niistä johdetut alivarmenteet hyväksytään sitten, kun ne avataan pyytämättä. Selaimen tiedossa oleva päävarmenne riippuu selainversiosta; Lisäksi varmenteiden luettelo päivitetään osittain myös verkossa osana järjestelmäpäivitystä, esimerkiksi Microsoft Windowsin kanssa.

Joissa Internet Explorer 7 , Microsoft, ja pian sen jälkeen myös Mozilla kanssa Firefox 3 , kiristetään varoitus rekisteröimättömien todistukset: Jos aiemmin vain pop-up ”Turvallisuus Notice” ilmestyi, joka vaihtelee sen mukaan, nimi, lähde ja todistuksen voimassaoloajan, nyt verkkosivuston sisältö on piilotettu ja näyttöön tulee varoitus, jossa suositellaan sivun käyttöä. Nähdäkseen tämän käyttäjän on sitten nimenomaisesti "lisättävä poikkeus". Varmenne, jota ei ole syötetty selaimeen, on siksi yhä sopimattomampi massasovelluksiin.

Kysymys siitä, mitkä varmenteet sisältyvät selaimeen, on toisinaan johtanut pitkiin keskusteluihin avoimen lähdekoodin yhteisössä, esimerkiksi ilmaisten varmenteiden tarjoajan CAcertin ja Mozilla Foundationin välillä , katso CAcert (luotettavuus) .

Let's Encrypt siirtyi verkkoon vuoden 2015 lopussa . jota Mozilla ja Electronic Frontier Foundation . Täällä tarjotaan kaikille ilmaisia ​​varmenteita, joiden tarkoituksena on edistää HTTPS: n leviämistä kokonaisuudessaan. Palvelimella tarvitaan kuitenkin erillinen ohjelmisto varmenteiden asentamiseksi ja päivittämiseksi jatkuvasti.

Palvelimen toiminta

SSL-kirjasto, kuten OpenSSL, vaaditaan ohjelmistona HTTPS-yhteensopivan verkkopalvelimen käyttämiseen . Tämä on usein jo toimitettu tai se voidaan asentaa moduulina. HTTPS -palvelu tarjotaan yleensä portissa 443.

todistus

Digitaalisen sertifikaatin on SSL , joka tarjoaa autentikointi Palvelimesta A Binärdokument joka yleensä on - - puolestaan sertifioitu Certificate Authority (CA Englanti sertifikaatin myöntäjän antamista) että palvelin ja domain selkeästi. Hakemuksessa tarkistetaan hakijan osoitetiedot ja yrityksen nimi.

Yleisiin selaimiin syötettyjä varmenteita tarjotaan tyypillisesti hintaan 15–600 euroa vuodessa, ja lisäpalvelut, sinetit tai vakuutukset sisältyvät tapauskohtaisesti. Monet varmentajat myöntävät todistuksia maksutta. Esimerkiksi Let's Encryptin myöntämät varmenteet hyväksytään lähes kaikissa nykyaikaisissa selaimissa ilman virheilmoitusta. CAcert luo myös ilmaisia ​​varmenteita, mutta toistaiseksi sitä ei ole voitu sisällyttää selaimen automaattisesti hyväksymään varmenteiden luetteloon; katso edellä . Tämän vuoksi käyttäjän on tuottava tällainen varmenne manuaalisesti asiakkaan käsittelyn aikana ; tämä käyttäytyminen voi kuitenkin olla toivottavaa.

Vanhentuneiden tai turvattomien kelpaamattomien varmenteiden selittämiseksi on annettu CRL ( englanninkielinen sertifikaatin peruutus , CRL ). Menettely edellyttää, että selaimet tarkistavat nämä luettelot säännöllisesti ja niissä estetyt varmenteet hylätään välittömästi.

Kun OCSP (Online Certificate Status Protocol), jota täydennetään SCVP (Palvelinpohjainen Certificate Validation Protocol), tuki todistus tarkastuksia voidaan toteuttaa palvelimen puolella.

Hyökkäyksistä varmennejärjestelmän, katso alla .

Itse allekirjoitettu

Palvelinoperaattori voi myös luoda itse allekirjoitettuja varmenteita maksutta ilman kolmannen osapuolen osallistumista. Selaimen käyttäjän on vahvistettava nämä manuaalisesti ("Lisää poikkeus"). Tässä tapauksessa mikään kolmas osapuoli ei takaa palveluntarjoajan aitoutta. Tällainen varmenne voidaan puolestaan ​​lähettää käyttäjälle etukäteen turvallisella tavalla ja tuoda hänen asiakassovellukseensa aitouden kartoittamiseksi toisella tavalla.

Laajennettu validointitodistus

HTTPS-suojattuja verkkosovelluksia vastaan ​​tapahtuvien lisääntyvien tietojenkalasteluhyökkäysten taustalla Yhdysvalloissa perustettiin vuonna 2007 CA / Browser Forum , joka koostuu sertifiointiorganisaatioiden ja selainvalmistajien edustajista. Kun se perustettiin, selainvalmistajat KDE, Microsoft, Mozilla ja Opera olivat mukana. Kesäkuussa 2007 hyväksyttiin ensimmäinen yhteinen ohje, laajennettu validointitodistus , EV-SSL lyhyesti versiossa 1.0, huhtikuussa 2008 versio 1.1.

Verkkotunnuksen operaattorin on hyväksyttävä tämän varmenteen lisätarkastukset: Vaikka aiemmin vain järjestelmänvalvojan saatavuus oli tarkistettava (puhelimitse ja sähköpostitse), hakijan postiosoite tarkistetaan nyt ja yritykset tarkistetaan valtuutettujen allekirjoittajien varalta. Tämä liittyy myös huomattavasti korkeampiin kustannuksiin.

EV -varmenne on havaittavissa käyttäjälle verkkopalveluntarjoajan lisäksi yrityksen osoiterivillä, joka on korostettu valkoisella ja vihreällä selaimissa vuodesta 2007 lähtien, sivuston logon oikealla puolella . Koska tälle verkkosivustolle tuttu lisäyritys puuttuu, käyttäjän pitäisi nyt pystyä tunnistamaan väärennetyt HTTPS -sivustot nopeasti ja tarvittaessa intuitiivisesti - eli ilman erityiskoulutusta.

IP -osoitteita useille verkkotunnuksille

Jo pitkään oli tarpeen, että jokaisella isäntänimellä on oltava erillinen IP -osoite HTTPS -verkkopalvelimen käyttämiseksi .

Tämä ei ole tarpeen salaamattoman HTTP: n kanssa: Koska selain on lähettänyt isäntänimen HTTP -ylätunnisteeseen , useita virtuaalisia verkkopalvelimia, joista jokaisella on oma isäntänimi, voidaan käyttää yhdellä IP -osoitteella, esimerkiksi Apachen kanssa käyttämällä Name VirtualHost -mekanismia . Tätä menettelyä käytetään nyt suurimmassa osassa verkkotunnuksia, koska verkkotunnuksen omistaja ei käytä palvelinta itse .

Koska HTTPS: n kanssa verkkopalvelimen on kuitenkin toimitettava erillinen varmenne kullekin isäntänimelle, mutta isäntänimi lähetetään vain ylemmässä HTTP -kerroksessa SSL -kättelyn jälkeen, isäntänimen ilmoittamista HTTP -otsikossa ei voida käyttää tässä. Tämä tarkoitti sitä, että eriyttäminen oli mahdollista vain IP / portti -yhdistelmän perusteella ; monet välityspalvelimet eivät jälleen hyväksy muuta porttia kuin 443 .

Tätä taustaa vasten jotkut palveluntarjoajat käyttivät kiertotietä , jotta asiakkaat voivat käyttää HTTPS -protokollaa ilman omaa IP -osoitetta, kuten "jaettua SSL -yhteyttä". He käyttivät yleismerkkejä, jotka ovat voimassa kaikille verkkotunnuksen aliverkkotunnuksille, asiakaskohtaisten aliverkkotunnusten yhteydessä. Muut palveluntarjoajat käyttivät "SSL -välityspalvelinta ", joka reititti kyselyt useiden asiakkaiden käyttämän verkkotunnuksen kautta.

Ratkaisu tähän ongelmaan tuli palvelimen nimen ilmaisulla (SNI), joka perustuu Transport Layer Security 1.2: een, koska selaimen pyytämä isäntänimi voidaan lähettää jo SSL -kättelyn aikana. Tämän myötä muut edellä mainitut tekniikat ovat tulleet merkityksettömiksi. Prosessi vaatii ajantasaista ohjelmistoa palvelin- ja selainpuolella, ja he ovat tukeneet sitä vuodesta 2006 lähtien.

Siinä tapauksessa Apache palvelin , SNI käsittely on esim. B. jota ohjataan vain hieman muokatulla kokoonpano -ohjeella:
<VirtualHost _default_:443>

Osallistuminen

HTTPS integroidaan verkkosivustoon tai sovellukseen samalla tavalla kuin edellä mainitut HTTPS-valinnat :

  • Jos vain HTTPS on sallittu, tämä voidaan toteuttaa seuraavasti:
  • Käyttäjälle kerrotaan mahdollisuudesta käyttää SSL: ää vastaavan linkin kautta.
    • Joissakin tapauksissa, etenkin HTTPS: n käyttöönoton aikana, linkin kautta tapahtuva sovellus jätetään käyttämättä. Käyttäjä voi siirtyä HTTPS -protokollaan vain manuaalisesti lisäämällä URL -osoitteeseen "http" -merkin jälkeen "s".
  • Skriptiohjattu HTTPS-linkkien luominen, joka ohjaa käyttäjän HTTPS-sivulle tiettyjä työvaiheita tai tuloksia varten. Voit sitten tarkistaa komentosarjasta, onko se kutsuttu HTTPS -protokollalla, esimerkiksi PHP: llä käyttämällä ehtoa:$_SERVER['HTTPS']=='on'

Vaihto

Suorittimen suorituskyvyn ja tietoturvatietoisuuden kasvaessa vaaditaan säännöllisesti muuntaa aiemmin HTTP -pohjainen verkkosivusto HTTPS -protokollaksi. Jos kyseessä on Stack Overflow -verkkosivusto, jossa on paljon käyttäjiä ja palveluita, tämä prosessi kestää useita vuosia, eikä se ole valmis maaliskuussa 2017. Muun muassa, työskenteli seuraavien aiheiden parissa:

  • Vältä salaamattomien tietojen (mediatiedot, tyylitaulukot jne.) Integroimista salattuun sivuun (ns. Sekoitettu sisältö ). Muussa tapauksessa annetaan selaimen varoituksia, kuten "Osa tästä sivusta ei ole suojattu" tai tietoja ei ladata.
  • Koko infrastruktuuri on muutettava SSL: ksi, mukaan lukien kuormituksen tasapainotuslaitteet ja välityspalvelimet
  • Varmenteiden järjestäminen tarvittaessa useille aliverkkotunnuksille
  • Oman verkkosovelluksesi koodin muuntaminen, jossa HTTP on kovakoodattu
  • Vanhan muunnos ja uuden käyttäjäkoodin tarkistaminen, joka voi käyttää HTTP: tä
  • Laatutarkastus
  • Käynnissä olevien istuntojen toteuttaminen menettämättä niiden sisältöä (24/7 toiminta)

tehoa

Kun yhteys on muodostettu, palvelin määrittelee salausalgoritmin. Teoriassa palvelimen tulisi orientoitua asiakkaan toiveisiin. Laskenta -ajan säästämiseksi stream -salaukset ovat kuitenkin edullisia palvelimilla, joilla on suuri tietoliikenne , koska ne ovat vähemmän laskennallisesti vaativia kuin lohkosalaimet , kuten AES tai Camellia . Monia pitkään käytettyjä menetelmiä, kuten RC4, pidetään turvattomina, joten suuret verkkoselaimet eivät ole enää tukeneet niitä vuodesta 2016 lähtien .

Ja laitteistokäyttöinen SSL -kiihdytin (käytetään palvelimen suorittimen SSL -kiihdyttimien vapauttamiseen ) tarjotaan: PCI -kortit, joissa on erityiset optimoidut prosessorit, joita käsitellään SSL -kirjastossa. On myös erillisiä, enimmäkseen telinerakenteisia laitteita, jotka salaavat automaattisesti HTTP-tietovirran osia. Lisäksi palvelimia on saatavana ohjelmoitavilla laskentayksiköillä, jotka saavuttavat korkeamman vastaavan SSL -kirjaston suorituskyvyn kuin vastaavat kuluttavat universaalit suorittimet, MAU ( Modular Arithmetic Unit ) Sunilta . Tämä erikoislaitteisto kilpailee kuitenkin tiiviisti suurprosessorivalmistajien Intelin ja AMD: n moniprosessori- ja moniydinjärjestelmien jatkuvan kehittämisen kanssa .

Esimerkiksi vuonna 2010 Gmailin salaus aiheutti alle 1% prosessorin kuormituksesta, alle 10 kt muistia tarvitaan yhteyttä kohti ja alle 2% verkkoliikenteestä . Kymmenen vuotta aikaisemmin salaustekniikka oli edelleen raskas taakka palvelimelle.

Hyökkäykset ja haavoittuvuudet

HTTPS-tekniikan tuntemuksen yleistymisen myötä myös hyökkäykset SSL-suojattuihin yhteyksiin ovat lisääntyneet. Lisäksi toteutuksen puutteet ovat tulleet ilmi tutkimuksella. Periaatteessa on tehtävä ero salauksen heikkojen kohtien ja varmennejärjestelmän välillä. Vuonna 2013 maailmanlaajuisen valvonta- ja vakoilutapauksen yhteydessä tuli tietoiseksi, että NSA käytti molempia hyökkäyskanavia päästäkseen salattuihin yhteyksiin.

Salaus

SSL: n kanssa käytetyt salausmenetelmät tarkistetaan säännöllisesti niiden tarkoituksesta riippumatta, ja niitä pidetään matemaattisesti turvallisina, ts. Toisin sanoen niitä ei teoriassa voida rikkoa nykyään tunnetuilla tekniikoilla. Algoritmien luotettavuus tarkistetaan säännöllisesti, esimerkiksi salakirjoittajien välisillä kilpailuilla . Teknisissä tiedoissa ja toteutuksissa poistetaan säännöllisesti tuki vanhentuneille salausmenetelmille, joita ei pidetä nykyisen tekniikan mukaan enää suojattuina, ja lisätään uusia menetelmiä.

Ongelmia ilmeni useita kertoja aiemmin, koska salausmenetelmä oli virheellisesti toteutettu. Erityisesti haavoittuvuudet laajassa OpenSSL -kirjastossa, kuten Heartbleed, saivat paljon julkista huomiota.

Koska käyttäjät eivät yleensä pyydä salattua yhteyttä määrittämällä HTTPS-protokollaa ( https: // ), kun he kutsuvat verkkosivustoa, hyökkääjä voi estää yhteyden salauksen ennen alustamista ja puolivälissä tapahtuvaa hyökkäystä .

HTTP Strict Transport Security tai HSTS -menettely otettiin käyttöön vuonna 2012 erityisesti suojautuakseen alemmilta hyökkäyksiltä salausta ja istunnon kaappausta vastaan . Se aktivoidaan palvelimen HSTS -otsikon avulla. http voidaan muuntaa https -URL -osoitteiksi.

Todistusjärjestelmä

SSL-yhteydet ovat pohjimmiltaan vaarassa välissä olevista man-hyökkäyksistä , joissa hyökkääjä sieppaa asiakkaan ja palvelimen välisen dataliikenteen esimerkiksi esiintymällä välittäjänä. Useat hyökkäysmenetelmät edellyttävät, että hyökkääjä on uhrin verkossa. Vuonna puolestaan DNS-huijaus ei täytä näitä vaatimuksia.

Jotta teeskennellä olevansa (eri) palvelin, hyökkääjän on myös näytettävä varmenne. Hän voi tehdä tämän esimerkiksi, jos hän onnistuu murtautumaan varmenneviranomaisen järjestelmään tai jos hänellä on muuten hallussaan varmenne, jolla voidaan myöntää mikä tahansa muu todistus. Tällaisia ​​mahdollisuuksia voi olla erityisesti vaikutusvaltaisten hyökkääjien, kuten valtion viranomaisten, tapauksessa, sillä joskus on olemassa myös valtion varmennuslaitoksia. Julkisen HTTP -avaimen kiinnitys ja varmenteiden läpinäkyvyys on suunniteltu tekemään tällaisista hyökkäyksistä vaikeampia.

Tietojenkalastelu ja HTTPS

Varmenteiden automaattisen vahvistuksen haittana on, että käyttäjä ei ole enää tietoinen HTTPS -yhteydestä. Tätä on äskettäin hyödynnetty tietojenkalasteluhyökkäyksissä, jotka simuloivat esimerkiksi verkkopankkisovelluksia ja simuloivat suojattua yhteyttä käyttäjälle syötettyjen PIN / TAN -koodien kalastamiseksi. Vastauksena asianomaiset yritykset kehottivat asiakkaitaan olemaan napsauttamatta sähköpostiviestien linkkejä ja syöttämään vain https -URL -osoitteet manuaalisesti tai kirjanmerkillä .

Sertifikaattien myöntämisen yhteydessä toisinaan pinnallisten tarkastusten vuoksi selainvalmistajat ottivat käyttöön laajennetun validoinnin sertifikaatin , katso edellä .

Sekoitettu sisältö

Salaamattomien resurssien lataaminen uudelleen mahdollistaa hyökkääjän salakuljettaa haitallista koodia alun perin salatulle verkkosivustolle käyttämällä man-in-the-middle -hyökkäystä . Siksi yleisten verkkoselainten nykyiset versiot estävät oletuksena salaamattomien resurssien lataamisen uudelleen. Samoin HTTP -evästeellä, jota käytetään sekä salattuihin että salaamattomiin yhteyksiin, on olemassa istunnon kaappaamisen vaara , vaikka todennus tapahtuisi salatun yhteyden kautta.

MD5 -haavoittuvuus

Kaaoksen 25. viestintäkongressissa Berliinissä joulukuussa 2008 julkaistiin onnistunut hyökkäys SSL -varmennejärjestelmää vastaan. Kryptologien välisessä kansainvälisessä yhteistyössä ja käyttämällä erityisesti ohjelmoitua laitteistoa - 200 Playstation 3 -pelikonsolia - on mahdollista luoda törmäys MD5 -algoritmiin , jonka perusteella hyökkääjä voi itse myöntää varmenteita. MD5 -algoritmin käyttöä ei aiemmin neuvottu asiantuntijapiireissä; sitä ei kuitenkaan voi käyttää EV -varmenteiden kanssa . Useimmat verkkoselaimet ovat lopettaneet MD5 -varmenteiden hyväksymisen vuodesta 2011 lähtien. Samanlaisten ongelmien välttämiseksi selainten valmistajat ilmoittivat tukevansa SHA1 -varmenteita vain rajoitetun ajan.

Tekniset tiedot

  • RFC 2818 - HTTP TLS: n kautta (englanti)

nettilinkit

Yksilöllisiä todisteita

  1. ↑ HSTS: n esilataus .
  2. ↑ Vain HTTPS-tila Firefoxissa. Lähde : support.mozilla.org. Käytetty 18. kesäkuuta 2021 .
  3. ↑ apache.org: Apache 2.5 OCSP Stapling , käytetty 23. heinäkuuta 2017.
  4. ↑ web.archive.org
  5. ↑ Internet Engineering Task Force: RFC 3546 , kesäkuu 2003, käytetty 10. maaliskuuta 2017.
  6. ↑ digitalocean.com: Kuinka asettaa useita SSL -varmenteita yhdelle IP -osoitteelle Apachen kanssa Ubuntussa 04/12 , 19. lokakuuta 2012, käytetty 9. maaliskuuta 2017.
  7. ↑ nickgeoghegan.net: Palvelimen nimen sisällyttäminen käyttöön Debian Squeeze -palvelussa , käytetty 23. heinäkuuta 2017.
  8. ↑ meta.stackexchange.com: Verkon laajuinen HTTPS: On aika , käytetty 9. maaliskuuta 2017.
  9. ↑ nickcraver.com: Stackoverflow.com: tie SSL: ään , käytetty 9. maaliskuuta 2017.
  10. ↑ Sekoitetun sisällön kuvaus osoitteessa www.w3.org.
  11. ↑ Emil Protalinski: Google, Microsoft ja Mozilla luopuvat RC4 -salauksesta Chromessa, Edgessä, IE: ssä ja Firefoxissa ensi vuonna , VentureBeat, 1. syyskuuta 2015.
  12. ↑ Neliytiminen Intel Xeon SSL -suorituskyky sivustolla anandtech.com, 27. joulukuuta 2006.
  13. ^ A b Adam Langley, Nagendra Modadugu, Wan-Teh Chang: SSL-ylikellotus. Julkaisussa: ImperialViolet. Adam Langleyn blogi. 25. kesäkuuta 2010, käytetty 23. lokakuuta 2014 .
  14. ↑ Esimerkki: Daniel Berger: Firefox 39 poistaa SSLv3: n ja RC4: n. Julkaisussa: Heise online . 3. heinäkuuta 2015, käytetty 22. lokakuuta 2015 . Daniel Berger: Firefox 27 salattu TLS 1.2: lla. Julkaisussa: Heise online . 4. helmikuuta 2014, käytetty 22. lokakuuta 2015 .
  15. ↑ Daniel Bachfeld: Black Hat: Uusia SSL -hyökkäysmenetelmiä. Julkaisussa: Heise online Security. 19. helmikuuta 2009. Haettu 25. lokakuuta 2015 .
  16. ↑ EFF epäilee SSL: n turvallisuutta heise -salauksen salakuuntelua vastaan , tarkastettu 28. kesäkuuta 2013.
  17. ↑ 25C3: Onnistunut hyökkäys SSL -varmennejärjestelmää vastaan . Vuodesta heise.de, 30. joulukuuta 2008, käytetty 3. tammikuuta 2013.
  18. ↑ Apple IOS5 , Firefox 16 , Microsoft Internet Explorer .
  19. ↑ Ivan Ristic: SHA1 Poisto: Mitä sinun tarvitsee tietää .