Kysymys:
Mitä eroa on SSL, TLS ja HTTPS?
jrdioko
2011-07-10 21:40:01 UTC
view on stackexchange narkive permalink

Sekaan tämän alueen termeihin. Mikä on SSL, TLS ja HTTPS? Mitä eroja niiden välillä on?

Katso osoitteesta https://www.trustworthyinternet.org/ssl-pulse/#chart-protocol-support sivustotuki eri SSL- ja TLS-versioille.
Joulukuu 2014: Odotetaan SSL-tuen laskevan nopeasti nyt, kun se on [korjaamattomasti rikki] (https://community.qualys.com/blogs/securitylabs/2014/10/15/ssl-3-is-dead-killed-by-the- villakoirahyökkäys). Selaimet ovat jo poistaneet sen ([Firefox välittömästi] (https://www.mozilla.org/en-US/firefox/34.0/releasenotes/), [Chrome varovasti] (https://groups.google.com/a/ chromium.org/d/msg/security-dev/Vnhy9aKM_l4/E0G5VPlb9B4J), [Internet Explorer osittain] (http://blogs.msdn.com/b/ie/archive/2014/12/09/december-2014-internet -explorer-security-updates-amp-disabled-ssl-3-0-fallback.aspx))
Kolme vastused:
#1
+548
Thomas Pornin
2011-07-10 21:47:42 UTC
view on stackexchange narkive permalink

TLS on SSL: n uusi nimi. Nimittäin SSL-protokolla pääsi versioon 3.0; TLS 1.0 on "SSL 3.1". Tällä hetkellä määritetyt TLS-versiot sisältävät TLS 1.1 ja 1.2. Jokainen uusi versio lisää muutamia ominaisuuksia ja muuttaa joitain sisäisiä yksityiskohtia. Sanomme joskus "SSL / TLS".

HTTPS on HTTP-SSL / TLS. SSL (TLS) muodostaa suojatun, kaksisuuntaisen tunnelin mielivaltaiselle binääridatalle kahden isännän välille. HTTP on protokolla pyyntöjen lähettämiseen ja vastausten vastaanottamiseen, kukin pyyntö ja vastaus koostuvat yksityiskohtaisista otsikoista ja (mahdollisesti) sisällöstä. HTTP on tarkoitettu toimimaan kaksisuuntaisen tunnelin yli mielivaltaisille binaaritiedoille; kun tunneli on SSL / TLS-yhteys, kokonaisuutta kutsutaan nimellä "HTTPS".

Lyhenteiden selittämiseksi:

  • "SSL" tarkoittaa "Secure Sockets Layer" . Tämän keksivät protokollan ensimmäiset versiot, Netscape (yrityksen AOL osti myöhemmin).
  • " TLS" tarkoittaa "Transport Layer Security". Nimeä muutettiin Netscapen oikeudellisten ongelmien välttämiseksi, jotta protokolla voisi olla "avoin ja ilmainen" (ja julkaistu RFC: ksi). Se vihjaa myös ajatukseen, että protokolla toimii kaikissa kaksisuuntaisissa tavuissa, ei pelkästään Internet-pohjaisissa pistorasioissa.
  • " HTTPS" oletetaan tarkoittavan "HyperText Transfer Protocol Secure" ", joka on kieliopillisesti perusteeton. Kukaan, paitsi lopullisesti kyllästynyt pedantti, ei koskaan käytä käännöstä; "HTTPS" on parempi ajatella "HTTP: ksi S: llä, joka tarkoittaa SSL: ää". Muut protokollalauseet on rakennettu samalla tavalla, esim. SMTPS, IMAPS, FTPS ... ne kaikki ovat paljaita protokollia, jotka "suojattiin" suorittamalla niitä joissakin SSL / TLS-palveluissa.
Hämmentävän täydellisyyden tekemiseksi: SSL (suojattu liitäntäkerros) viittaa usein vanhaan protokollamuunnelmaan, joka alkaa heti kädenpuristuksella ja vaatii siksi salatulle protokollalle toisen portin, kuten 443 80: n sijaan. TLS (siirtokerroksen suojaus) viittaa usein uuteen muunnokseen, jonka avulla voidaan aloittaa salaamattomalla perinteisellä protokollalla ja antaa sitten komento (yleensä STARTTLS) kädenpuristuksen alustamiseksi.
SSL: ää ei enää ole. Siellä on TLS 0.9 ja mielettömälle TLS-versio -0.1.
@Hendrik, En ole varma, kutsuisin kädenpuristuksen aloittamista "vanhaksi" variantiksi ja sitä, joka päivittää saman portin (a la STARTTLS), "uudeksi" variantiksi. He ovat vain erilaisia. Olen aina pitänyt argumentteja, joiden mukaan toinen on turvallisempi kuin toinen, erittäin subjektiivisia: molemmat lähestymistavat on määritettävä ja niitä on käytettävä oikein turvallisuuden takaamiseksi.
@thejh, hups, hyvä saalis.
Älä sekoita ongelmaa mainitsemalla STARTTLS! TLS ja SSL tarjoavat yleisen suojatun yhteyden, jota voidaan käyttää minkä tahansa protokollan lähettämiseen sen kautta: Kun HTTP-protokolla lähetetään TLS: n tai SSL: n kautta, sitä kutsutaan HTTPS: ksi. STARTTLS-ominaisuus on käytettävissä vain SMTP-sähköpostinvaihtoprotokollassa, eikä sillä ole mitään tekemistä HTTP: n tai HTTPS: n kanssa. TLS ja SSL eivät tiedä mitään STARTSSL-komennosta. Sekä TLS että SSL alkavat aina kädenpuristuksella suojatun yhteyden muodostamiseksi.
Jos TLS ja SSL ovat olennaisilta osin sama asia, miten voi luoda sähköpostitiliä Outlookissa, salausvaihtoehdot ovat SSL tai TLS?
SMTP: llä ja IMAP: lla on kaksi tapaa käyttää SSL: ää: yksi on samanlainen kuin HTTPS (aloitat SSL: llä ja tunnelissa käytät tavallista protokollaa), toinen käyttää `STARTTLS` -komentoa (aloitat tavallisella protokollalla) ja vaihda sitten SSL: ään jonkin neuvottelun jälkeen). Asiakkaan on tiedettävä, mitä tehdä etukäteen (varsinkin koska molemmat menetelmät eivät käytä samaa porttia: 143 IMAP + STARTTLS, 993 ja IMAP-SSL sisällä). Sekaannusten yleisenä ylivaltaajana Microsoft päätti kutsua näitä kahta menetelmää "SSL" ja "TLS".
@Hoylen Kiitos, että mainitsit STARTTLS: n, joka ei ole osa SMTP: tä.Luin STARTTLS: n ja aloin mennä polkua pitkin, joka olisi johtanut pimeälle puolelle.
#2
+66
Bruno
2011-07-11 13:59:06 UTC
view on stackexchange narkive permalink

SSL ja TLS ovat protokollia, joiden tarkoituksena on tarjota yksityisyyttä ja tietojen eheyttä kahden osapuolen välillä (katso RFC 2246) ja jotka on suunniteltu toimimaan luotettavan tiedonsiirtoprotokollan (yleensä TCP) yli. Vaikka TLS-määrityksessä ei puhuta pistorasioista, SSL / TLS suunniteltiin siten, että sovellukset voisivat käyttää niitä melkein kuin perinteiset TCP-liitännät, esimerkiksi Java SSLSocket laajentaa Socket (käytettävyydessä on kuitenkin pieniä eroja).

HTTPS on HTTP SSL / TLS: n kautta, jossa ensin muodostetaan SSL / TLS-yhteys, ja sitten normaalia HTTP-dataa vaihdetaan tällä SSL: llä SSL- tai TLS-yhteys riippuu selaimesi ja palvelimen kokoonpanosta (yleensä on mahdollisuus sallia SSLv2, SSLv3 tai TLS 1.x). HTTPS-lomakkeen tiedostot ovat RFC 2818.

SSL: n ja TLS: n erojen suhteen saatat olla kiinnostunut näistä kahdesta vastauksesta, jotka kirjoitin näihin vastaaviin kysymyksiin StackOverflow- ja ServerFault-tiedostoissa:

Voisit pitää TLSv1.0: ta SSLv3.1: nä (itse asiassa näin tapahtuu vaihdetuissa tietueissa). On vain helpompaa verrata TLSv1.0: ta TLSv1.1: een ja TLSv1.2: een, koska niitä kaikkia on muokattu IETF: ssä ja ne noudattavat suunnilleen samaa rakennetta. SSLv3: ta muokkaa jokin muu laitos (Netscape), se tekee siitä hieman vaikeamman, joten huomaa erot.

Tässä on muutamia eroja, mutta epäilen, voinko luetella ne kaikki:

  • ClientHello-viestissä (ensimmäinen asiakkaan lähettämä viesti kädenpuristuksen aloittamiseksi) versio on {3,0} SSLv3: lle, {3,1} TLSv1.0: lle ja {3,2} mallille TLSv1.1.
  • ClientKeyExchange eroaa.
  • MAC / HMAC eroaa (TLS käyttää HMAC: ää, kun taas SSL käyttää HMAC: n aikaisempaa versiota).
  • Avainten johtaminen on erilaista.
  • Asiakas voi lähettää sovellustiedot voidaan lähettää heti, kun se on lähettänyt SSL / TLS Valmis -sanoman SSLv3: ssa. TLSv1: ssä sen on odotettava palvelimen Valmis-viestiä.
  • Salauspakettien luettelo eroaa (ja jotkut niistä on nimetty uudelleen SSL_ *: sta TLS_ *: ksi, säilyttäen sama tunnusnumero).
  • Uudessa neuvottelulaajennuksessa on myös eroja.

Yleensä mitä korkeampi versio tai SSL / TLS on, sitä turvallisempi se on, jos valitse myös salauspakettisi oikein (TLS: n korkeammat versiot tarjoavat myös parempana pidettyjä salauspaketteja). (SSLv2: ta pidetään epävarmana.) Lisäksi SSL ei kuulu IETF: n soveltamisalaan. Esimerkiksi TLS-neuvottelujen korjaus oli asennettava uudelleen SSLv3: lle (vaikka SSL / TLS-pinot oli joka tapauksessa päivitettävä).

Saatat myös olla kiinnostunut tästä vastauksesta:

Huomautus jotkut ihmiset vastustavat SSL: ää ja TLS: ää erona "SSL / TLS: n muodostamisen yhteydessä" ja "päivitä TLS: ään" (jonkin keskustelun jälkeen sovellusprotokollaa käyttäen). Huolimatta siitä, että jotkut näistä vastauksista ovat suhteellisen voimakkaasti äänestettyjä, tämä on väärin. Tätä virhettä leviää se tosiasia, että tietyt sovellukset, kuten Microsoft Outlook, tarjoavat kaksi määritysvaihtoehtoa "SSL" ja "TLS" SMTP / IMAP-kokoonpanolle, kun ne todella tarkoittavat "SSL / TLS yhteyden muodostamisen yhteydessä" ja "päivitä TLS: ksi". (Sama pätee mielestäni JavaMail-kirjastoon.)

STARTTLS: stä puhuvat RFC: t kirjoitettiin, kun TLS oli jo virallinen RFC, siksi he puhuvat vain yhteyden päivittämisestä TLS: ään. Käytännössä, jos muokkaat sähköpostiohjelman kokoonpanoa pakottaaksesi sen käyttämään SSLv3: ta TLS: n sijaan (ei jotain, jota suosittelisin yleensä), se todennäköisesti pystyy päivittämään SSL / TLS: ksi käyttämällä STARTTLS: ää SSLv3-yhteydellä, yksinkertaisesti koska kyse on enemmän toimintatavasta kuin SSL / TLS-versiosta ja / tai salauspaketeista.

On myös HTTP-muunnos, jossa päivitys SSL / TLS: ksi tehdään HTTP-protokollan sisällä ( (samanlainen kuin STARTTLS LDAP / SMTP: ssä). Tämä on kuvattu julkaisussa RFC 2817. Sikäli kuin tiedän, tätä ei käytetä melkein koskaan (eikä sitä käytetä selaimissa https: // ). Tämän RFC: n tärkein osa on CONNECT -osio HTTP-välityspalvelimille (HTTP-välityspalvelimet käyttävät tätä välittämään HTTPS-yhteyksiä).

RFC 2817: tä ei käytetä käytännössä, koska se sekoittaa liikaa HTTPS-asiakkaan sisäisen rakenteen. Sen sijaan asiakkaat käyttävät nyt "Palvelimen nimen ilmaisua" saman ongelman ratkaisemiseksi, nimittäin aiotun palvelimen nimen mainostamiseksi _ ennen kuin palvelin lähettää varmenteensa (tämä on tarkoitettu virtuaalipalvelimelle); SNI on laajennus, jonka asiakas on lisännyt TLS-kädenpuristuksen alkuun.
@Thomas, suostui, mutta ero. HTTPS: n (kuten käytämme) ja RFC 2817: n välillä olisi ollut sama kuin SMTPS: n ja STMP + STARTTLS: n välillä. Itse asiassa yksi sen käsittelemistä kohdista on sama ongelma kuin SNI, mutta mielestäni kysyntää oli tuolloin vähemmän, ja RFC 2817: tä tukevat asiakkaat / palvelimet eivät koskaan lähteneet. Varmista, että URI oli näkyvästi `` https: // '' (jotta se olisi todennäköisesti turvallisempi?), Näyttää olevan argumentti selkeän eron säilyttämiseksi (mahdollisesti läpinäkyvän päivityksen sijasta), AFAIK. Keskustelu käydään myös täällä: http://www.ietf.org/mail-archive/web/tls/current/msg01096.html
Kirjoitat `SSLv3 over TLS` Onko se jonkinlainen kirjoitusvirhe? Mitä tarkoitat? Ymmärrän sen, että versiot menivät jotain SSL v1 SSL v2 SSL v3 TLS v1.0 TLS v1.1 TLS v1.2 Joten sanoa "SSLv3 TLS: n kautta" on kuin sanoa Windows 98 Windows 7: n tai salaus salauksen sisällä. Mitä tarkoitat?
@barlop Anteeksi, se oli todellakin huonosti muotoiltu, tarkoitin sitä "sijasta".
#3
+18
Vishwanath Dalvi
2011-07-10 23:53:49 UTC
view on stackexchange narkive permalink

SSL VS TLS

Termejä SSL ja TLS käytetään usein vaihdettavasti tai yhdessä toistensa kanssa (TLS / SSL), mutta yksi on itse asiassa toisen edeltäjä - SSL 3.0 toimi TLS 1.0: n perusta, jota tästä syystä kutsutaan joskus SSL 3.1: ksi.

Mikä on turvallisempaa SSL: ää tai TLS: ää

Turvallisuuden kannalta molempia pidetään yhtä turvallisina

Tärkein ero on, että vaikka SSL-yhteydet alkavat suojauksella ja etenevät suoraan suojattuun tietoliikenteeseen, TLS-yhteydet alkavat ensin epävarmalla "hei" palvelimelle ja siirtyvät suojattuun tietoliikenteeseen vasta asiakkaan kädenpuristuksen jälkeen. ja palvelin on onnistunut. Jos TLS-kättely epäonnistuu jostain syystä, yhteyttä ei koskaan luoda.

(SSL ja TLS vs HTTP)

HTTP-protokollaa käytetään tietojen ja https: n pyytämiseen ja vastaanottamiseen. 's' ei ole muuta kuin suojattu SSL, joka tekee http-protokollan pyynnöstä ja toiminnasta salatun, joten kukaan keski-iskuista hyökkääjä ei voi saada tietoja helposti.

Jos HTTP: n kanssa ei käytetä SSL: ää eikä TLS: ää

sitten yhteys Web-palvelimeen on salaamaton, kaikki tiedot lähetetään selkeällä tekstillä, jonka kuka tahansa keskitahoinen hyökkääjä voi hankkia ja tarkastella kyseisiä tietoja.

Joten pitäisi mennä SSL: n tai TLS: n kanssa

hyvin, molemmat ovat samat, mutta TLS on laajennettavissa ja toivoen saada enemmän tukea tulevaisuudessa ja TLS on taaksepäin yhteensopiva.

Valitettavasti -1 *: lle: "Tärkein ero on, että vaikka SSL-yhteydet alkavat suojauksella ja etenevät suoraan suojattuun tietoliikenteeseen, TLS-yhteydet alkavat ensin epävarmalla" hei "-palvelimella ja siirtyvät suojattuun tietoliikenteeseen vasta kädenpuristuksen jälkeen. ja palvelin on onnistunut. "*. SSLv3- ja TLS-yhteydet aloitetaan kädenpuristuksella, joka tehdään samalla tavalla (molemmat alkavat `ClientHello`: lla). Saatat olla hämmentävä SSL / TLS-yhteys ja päivittää TLS: ään jotain `` STARTTLS ''.
TLS 1.2 tukee lopulta SHA-2-pohjaista HMAC: ää, joten teoriassa uusien käyttöönottojen tulisi käyttää vain TLS 1.2 *
@Bruno väite, jonka mukaan alkuperäinen selkeä teksti on TLS: n ja SSL: n ero, on todellakin väärä, epäilen kuitenkin, että sekaannus ei johdu SMTP-yhteyden päivityksestä, vaan pikemminkin TLS: n ** palvelimen nimen indikaatiosta (SNI) ** * laajennuksesta *, jolloinvirtuaalipalvelimen isännälle kerrotaan ensin selkeässä tekstissä, mille isäntänimistä kädenpuristus suoritetaan (ja laajennuksella mitä sertifikaattia käytetään).Joten se on todellakin väärä väite itse TLS: lle *, mutta se on todennäköisesti hieman * lähempänä * piti.


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...