Keamanan Lapisan Transportasi: Perbedaan antara revisi
Konten dihapus Konten ditambahkan
Fitur saranan suntingan: 3 pranala ditambahkan. Tag: halaman dengan galat kutipan VisualEditor Tugas pengguna baru Disarankan: tambahkan pranala |
|||
| (96 revisi perantara oleh 40 pengguna tidak ditampilkan) | |||
Baris 1:
'''Keamanan Lapisan Transportasi''' {{Lang-en|Transport Layer Security}} (TLS), dan pendahulunya yang sudah usang, '''Secure Sockets Layer''' (SSL),<ref>{{Cite web|url=https://tools.ietf.org/html/rfc7568.html|title=Deprecating Secure Sockets Layer Version 3.0|last=Langley|first=Adam|last2=Pironti|first2=Alfredo|website=tools.ietf.org|language=en|access-date=2020-05-30|last3=Barnes|first3=Richard|last4=Thomson|first4=Martin}}</ref> adalah [[protokol kriptografi]] yang dirancang untuk memberikan keamanan komunikasi melalui [[jaringan komputer]].<ref name=":0">{{Cite web|url=https://tools.ietf.org/html/rfc5246.html|title=The Transport Layer Security (TLS) Protocol Version 1.2|last=Rescorla <ekr@networkresonance.com>|first=Eric|website=tools.ietf.org|language=en|access-date=2020-05-30}}</ref> Beberapa versi protokol TLS dapat ditemukan penerapannya secara luas seperti di [[peramban web]], [[Surat elektronik|surel]], [[pesan instan]], dan [[voice over IP]] (VoIP). [[Situs web]] dapat menggunakan TLS untuk mengamankan semua komunikasi antara [[peladen]] dan [[peramban web]].
Protokol TLS bertujuan terutama untuk memberikan [[privasi]] dan integritas data antara dua atau lebih aplikasi komputer yang berkomunikasi.<ref name=":0" /> Ketika diamankan oleh TLS, koneksi antara klien (misalnya, peramban web) dan peladen (misalnya, wiki-indonesia.club) harus memiliki satu atau beberapa properti berikut:
* Koneksi bersifat ''pribadi'' (atau aman) karena kriptografi simetris digunakan untuk [[Enkripsi|mengenkripsi]] data yang dikirimkan. [[Kunci (kriptografi)|Kunci]] untuk enkripsi simetris ini dihasilkan secara unik untuk setiap koneksi dan didasarkan pada rahasia bersama yang dinegosiasikan pada awal sesi. Peladen dan klien menegosiasikan perincian algoritma enkripsi dan kunci kriptografi mana yang digunakan sebelum [[byte|bita]] pertama data ditransmisikan. Negosiasi rahasia bersama aman (rahasia yang dinegosiasikan tidak tersedia untuk penyadap dan tidak dapat diperoleh, bahkan oleh penyerang yang menempatkan diri di tengah-tengah koneksi) dan dapat diandalkan (tidak ada penyerang dapat memodifikasi komunikasi selama negosiasi tanpa menjadi terdeteksi).
* Identitas pihak yang berkomunikasi dapat ''diautentikasi'' menggunakan kunci kriptografi publik. Otentikasi ini dapat dibuat opsional, tetapi umumnya diperlukan untuk setidaknya salah satu pihak (biasanya peladen).
* Koneksi ini dapat ''diandalkan'' karena setiap pesan yang dikirim mencakup pemeriksaan integritas pesan menggunakan [[kode otentikasi pesan]] untuk mencegah kehilangan atau perubahan data yang tidak terdeteksi selama [[Transmisi data|transmisi]].<ref name=":0" />
Selain properti di atas, konfigurasi TLS yang hati-hati dapat memberikan properti terkait privasi tambahan seperti forward secrecy, memastikan bahwa setiap pengungkapan kunci enkripsi di masa depan tidak dapat digunakan untuk mendekripsi setiap komunikasi TLS yang direkam yang sebelumnya.<ref>{{Cite web|url=https://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html|title=SSL: Intercepted today, decrypted tomorrow|website=Netcraft News|language=en-gb|access-date=2020-05-31}}</ref>
== Deskripsi ==
Aplikasi [[Client/server|klien-server]] menggunakan [[Protokol eksklusif|protokol]] TLS untuk berkomunikasi melalui jaringan dengan cara yang dirancang untuk mencegah penyadapan dan gangguan.
Karena aplikasi dapat berkomunikasi dengan atau tanpa TLS (atau SSL), maka perlu bagi klien untuk menunjukkan ke server pengaturan koneksi TLS.<ref>{{Cite web|url=https://tools.ietf.org/html/rfc2817.html|title=Upgrading to TLS Within HTTP/1.1|last=Lawrence|first=Scott|last2=Khare|first2=Rohit|website=tools.ietf.org|language=en|access-date=2020-05-30}}</ref> Salah satu cara utama untuk mencapai ini adalah dengan menggunakan [[Port (Jaringan Komputer)|nomor port]] yang berbeda untuk koneksi TLS, misalnya port 443 untuk [[HTTPS]]. Mekanisme lain adalah bagi klien untuk membuat permintaan khusus protokol ke server untuk mengalihkan koneksi ke TLS; misalnya, dengan membuat permintaan [[TLS oportunistik|STARTTLS]] saat menggunakan protokol surat dan berita.
Setelah klien dan server setuju untuk menggunakan TLS, mereka menegosiasikan koneksi stateful dengan menggunakan prosedur handshaking.<ref>{{Cite web|url=https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc785811(v=ws.10)|title=SSL/TLS in Detail|last=Archiveddocs|website=docs.microsoft.com|language=en-us|access-date=2020-05-30}}</ref> Protokol menggunakan jabat tangan dengan cipher asimetris untuk membangun tidak hanya pengaturan cipher tetapi juga kunci bersama sesi khusus dengan mana komunikasi lebih lanjut dienkripsi menggunakan cipher simetris. Selama jabat tangan ini, klien dan server menyetujui berbagai parameter yang digunakan untuk membangun keamanan koneksi:
* Jabat tangan dimulai ketika klien terhubung ke server yang mendukung TLS yang meminta koneksi aman dan klien menyajikan daftar suite sandi yang didukung ( enkripsi dan [[Fungsi hash kriptografis|fungsi hash]]).
* Dari daftar ini, server memilih fungsi cipher dan hash yang juga mendukung dan memberi tahu klien tentang keputusan tersebut.
* Server biasanya kemudian memberikan identifikasi dalam bentuk [[Sertifikat kunci publik|sertifikat digital]]. Sertifikat tersebut berisi nama server, otoritas sertifikat tepercaya (CA) yang menjamin keaslian sertifikat, dan kunci enkripsi publik server.
* Klien mengonfirmasi validitas sertifikat sebelum melanjutkan.
*Untuk menghasilkan kunci sesi yang digunakan untuk koneksi aman, klien:
**mengenkripsi [[Pembuatan angka acak|nomor acak]] dengan kunci publik server dan mengirimkan hasilnya ke server (yang hanya server yang dapat mendekripsi dengan kunci privatnya); kedua belah pihak kemudian menggunakan nomor acak untuk menghasilkan kunci sesi unik untuk enkripsi dan dekripsi data berikutnya selama sesi.
**menggunakan [[pertukaran kunci Diffie-Hellman]] untuk secara aman menghasilkan kunci sesi acak dan unik untuk enkripsi dan dekripsi yang memiliki properti tambahan kerahasiaan maju: jika kunci pribadi server diungkapkan di masa depan, itu tidak dapat digunakan untuk mendekripsi sesi saat ini, bahkan jika sesi dicegat dan direkam oleh pihak ketiga.
Ini menyimpulkan jabat tangan dan memulai koneksi aman, yang dienkripsi dan didekripsi dengan kunci sesi hingga koneksi ditutup. Jika salah satu dari langkah-langkah di atas gagal, maka jabat tangan TLS gagal dan koneksi tidak dibuat.
TLS dan SSL tidak cocok dengan lapisan tunggal [[model OSI]] atau [[Paket protokol internet|model TCP / IP]].<ref>{{Cite book|url=https://books.google.com/books?id=5PJisOKJ0k8C&pg=PA22|title=CCNP Security VPN 642-648 Official Cert Guide: CCNP Sec VPN 642-648 ePub _2|last=Hooper|first=Howard|date=2012-06-22|publisher=Cisco Press|isbn=978-0-13-296638-2|language=en}}</ref> TLS menjalankan "di atas beberapa protokol transportasi yang andal (mis., TCP),"<ref name=":1">{{Cite web|url=https://tools.ietf.org/html/rfc5246.html|title=The Transport Layer Security (TLS) Protocol Version 1.2|last=Rescorla <ekr@networkresonance.com>|first=Eric|website=tools.ietf.org|language=en|access-date=2020-05-31}}</ref> yang akan menyiratkan bahwa protokol itu berada di atas [[lapisan transpor]]t. Ini melayani enkripsi ke lapisan yang lebih tinggi, yang biasanya merupakan fungsi dari [[lapisan presentasi]]. Namun, aplikasi umumnya menggunakan TLS seolah-olah itu adalah lapisan transport, meskipun aplikasi yang menggunakan TLS harus secara aktif mengontrol memulai jabat tangan TLS dan menangani sertifikat otentikasi yang dipertukarkan.<ref name=":1" />
== Sejarah dan pengembangan ==
=== Sistem Keamanan Jaringan Data ===
{| class="wikitable sortable" style="float:right; text-align:center; margin-left:1em;"
|+Protokol SSL dan TLS
! scope="col" |Protokol
! scope="col" |Diterbitkan
! scope="col" |Status
|-
! scope="row" |SSL 1.0
| {{n/a|Tidak diterbitkan}}
| {{n/a|Tidak diterbitkan}}
|-
! scope="row" |SSL 2.0
|1995
|Dihentikan pada tahun 2011 (RFC 6176)
|-
! scope="row" |SSL 3.0
|1996
|Dihentikan pada tahun 2015 (RFC 7568)
|-
! scope="row" |TLS 1.0
|1999
|Dihentikan pada tahun 2020<ref name=":2" /><ref name=":3">{{Cite web|url=https://www.ghacks.net/2020/03/10/here-is-what-is-new-and-changed-in-firefox-74-0-stable/|title=Here is what is new and changed in Firefox 74.0 Stable - gHacks Tech News|website=www.ghacks.net|access-date=2020-03-10}}</ref><ref name=":4">{{Cite web|url=https://chromestatus.com/feature/5759116003770368|title=TLS 1.0 and TLS 1.1 - Chrome Platform Status|website=chromestatus.com|access-date=2020-03-10}}</ref>
|-
! scope="row" |TLS 1.1
|2006
|Dihentikan pada tahun 2020<ref name=":2" /><ref name=":3" /><ref name=":4" />
|-
! scope="row" |TLS 1.2
|2008
|
|-
! scope="row" |TLS 1.3
|2018
|
|}
[[Transport Layer Security]] Protocol (TLS) bersama dengan beberapa platform keamanan jaringan dasar lainnya, dikembangkan melalui inisiatif bersama yang dimulai pada Agustus 1986, di antara [[Badan Keamanan Nasional]], Biro Standar Nasional, Badan Komunikasi Pertahanan, dan dua belas komunikasi dan komputer perusahaan yang memulai proyek khusus yang disebut Secure Data Network System (SDNS). Program ini dijelaskan pada bulan September 1987 di Konferensi [[Keamanan komputer|Keamanan Komputer]] Nasional ke-10 dalam serangkaian makalah yang diterbitkan.
Program penelitian inovatif ini berfokus pada perancangan generasi berikutnya dari jaringan komunikasi komputer yang aman dan spesifikasi produk yang akan diimplementasikan untuk aplikasi pada jaringan publik dan swasta. Itu dimaksudkan untuk melengkapi standar internet OSI baru yang berkembang pesat baik dalam profil GOSIP pemerintah AS dan dalam upaya internet ITU-ISO JTC1 yang besar secara internasional. Awalnya dikenal sebagai protokol SP4, namanya diganti TLS dan kemudian diterbitkan pada tahun 1995 sebagai standar internasional ITU-T X.274 | ISO / IEC 10736: 1995.
=== Keamanan Pemrograman Jaringan ===
Upaya-upaya penelitian awal terhadap keamanan lapisan transport mencakup antarmuka pemrograman aplikasi [[Secure Network Programming]] (SNP) [[Application Programming Interface|antarmuka pemrograman aplikasi]] (API), yang pada tahun 1993 mengeksplorasi pendekatan memiliki API lapisan transport aman yang mirip dengan [[Berkeley sockets|soket Berkeley]], untuk memfasilitasi perkuatan aplikasi jaringan yang sudah ada sebelumnya dengan keamanan Pengukuran.<ref name="Woo94">Thomas Y. C. Woo, Raghuram Bindignavle, Shaowen Su and [[Simon S. Lam]], [//www.cs.utexas.edu/users/lam/Vita/Cpapers/WBSL94.pdf ''SNP: An interface for secure network programming''] Proceedings USENIX Summer Technical Conference, June '''1994'''</ref>
== Aplikasi dan penerapan ==
Dalam desain aplikasi, TLS biasanya diimplementasikan di atas protokol Transport Layer, mengenkripsi semua data protokol terkait protokol seperti [[Http|HTTP]], [[Ftp|FTP]], [[SMTP]], [[NNTP]] dan [[XMPP]].
Secara historis, TLS telah digunakan terutama dengan protokol transportasi yang andal seperti Transmission Control Protocol (TCP). Namun, itu juga telah diimplementasikan dengan protokol transportasi berorientasi datagram, seperti User Datagram Protocol (UDP) dan Datagram Congestion Control Protocol (DCCP), penggunaan yang telah distandarisasi secara independen menggunakan istilah Datagram Transport Layer Security (DTLS) .
=== Situs web ===
Penggunaan utama TLS adalah untuk mengamankan lalu lintas World Wide Web antara suatu situs web dan peramban web yang disandikan dengan protokol HTTP. Penggunaan TLS ini untuk mengamankan lalu lintas HTTP merupakan protokol HTTPS.<ref>{{Cite web|url=https://www.instantssl.com/ssl-certificate-products/https.html|title="Http vs https".|last=|first=|date=|website=www.instantssl.com|access-date=2020-05-30}}</ref>
{|class="wikitable" style="text-align: center;"
|+Dukungan protokol situs web
|-
!Versi<br />protokol
!Dukungan<br />situs web<ref name="trustworthy_ssl_pulse">As of August 3, 2019. {{cite web |url=https://www.ssllabs.com/ssl-pulse/ |title=SSL Pulse: Survey of the SSL Implementation of the Most Popular Websites |website=[[Qualys]] |accessdate=2019-09-01}}</ref>
!Keamanan<ref name="trustworthy_ssl_pulse"/><ref name="community.qualys">{{cite web|url=https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what|accessdate=2013-07-30|publisher=Qualsys Security Labs|author=ivanr|title=RC4 in TLS is Broken: Now What?|url-status=live|archiveurl=https://web.archive.org/web/20130827044512/https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what|archivedate=2013-08-27}}</ref>
|-
!SSL 2.0
|1.6%
|{{Bad|Tidak aman}}
|-
!SSL 3.0
|6.7%
|{{Bad|Tidak aman<ref name="poodle_pdf" />}}
|-
!TLS 1.0
|65.0%
|{{Depends|Tergantung pada cipher<ref group="n" name="ciphers"></ref> and client mitigations<ref group="n" name="mitigations">see [[#Web browsers|§ Web browsers]] dan [[#Attacks against TLS/SSL|§ Attacks against TLS/SSL]] sections</ref>}}
|-
!TLS 1.1
|75.1%
|{{Depends|Tergantung pada cipher<ref group="n" name="ciphers"/> dan mitigasi klien<ref group="n" name="mitigations"/>}}
|-
!TLS 1.2
|96.0%
|{{Depends|Tergantung pada cipher<ref group="n" name="ciphers"/> dan mitigasi klien<ref group="n" name="mitigations"/>}}
|-
!TLS 1.3
|18.4%
|{{Good|Aman}}
|}
; Catatan
{{reflist|group="n"}}
== Sertifikat digital ==
{{Utama|Sertifikat kunci publik}}
[[Berkas:Let’s Encrypt example certificate on Firefox 94 screenshot.png|jmpl|Contoh situs web dengan sertifikat digital]]
Sertifikat digital mengesahkan kepemilikan kunci publik oleh subjek bernama sertifikat, dan menunjukkan penggunaan yang diharapkan dari kunci tersebut. Ini memungkinkan orang lain (mengandalkan pihak) untuk mengandalkan tanda tangan atau pada pernyataan yang dibuat oleh kunci pribadi yang sesuai dengan kunci publik bersertifikat.
=== [[Kekuasaan (hubungan internasional)|Otoritas]] sertifikat ===
{{Main|Otoritas sertifikat}}
TLS biasanya bergantung pada sekumpulan otoritas sertifikat pihak ketiga yang tepercaya untuk menetapkan keaslian sertifikat. Kepercayaan biasanya berlabuh dalam daftar sertifikat yang didistribusikan dengan [[perangkat lunak]] agen pengguna,<ref>{{Cite web|url=https://www.rsaconference.com/writable/presentations/file_upload/sec-t02_final.pdf|title=Alternatives to Certification Authorities for a Secure Web|last=Rea|first=Scott|date=2013|website=|publisher=RSA Conference Asia Pacific|archiveurl=https://web.archive.org/web/20161007222635/https://www.rsaconference.com/writable/presentations/file_upload/sec-t02_final.pdf|archivedate=7 October 2016|access-date=7 September 2016|url-status=live|df=}}</ref> dan dapat dimodifikasi oleh pihak yang mengandalkan.
Menurut [[Netcraft]], yang memantau sertifikat TLS aktif, otoritas sertifikat terkemuka pasar (CA) telah menjadi Symantec sejak awal survei mereka (atau [[VeriSign]] sebelum unit bisnis layanan otentikasi dibeli oleh Symantec). Pada 2015, Symantec menyumbang hanya di bawah sepertiga dari semua sertifikat dan 44% dari sertifikat yang valid yang digunakan oleh 1 juta situs tersibuk, sebagaimana dihitung oleh Netcraft.<ref>{{Cite web|url=https://news.netcraft.com/archives/2015/05/13/counting-ssl-certificates.html|title=Counting SSL certificates|website=Netcraft News|language=en-gb|access-date=2020-05-30}}</ref> Pada 2017, Symantec menjual bisnis TLS / SSL ke DigiCert.<ref>{{Cite web|url=https://www.deseret.com/2017/8/3/20616930/lehi-s-digicert-swallows-web-security-competitor-in-1-billion-deal|title=Lehi's DigiCert swallows web security competitor in $1 billion deal|last=Raymond|first=Art|date=2017-08-03|website=Deseret News|language=en|access-date=2020-05-30}}</ref> Dalam laporan terbaru, ditunjukkan bahwa [[IdenTrust]], [[DigiCert]], dan [[Sectigo]] adalah 3 otoritas sertifikat teratas dalam hal pangsa pasar sejak Mei 2019.<ref>{{Cite web|url=https://w3techs.com/technologies/history_overview/ssl_certificate|title=Market share trends for SSL certificate authorities, May 2020|website=w3techs.com|access-date=2020-05-30}}</ref>
Sebagai konsekuensi dari pemilihan sertifikat [[X.509]], otoritas sertifikat dan [[infrastruktur kunci publik]] diperlukan untuk memverifikasi hubungan antara sertifikat dan pemiliknya, serta untuk menghasilkan, menandatangani, dan mengelola validitas sertifikat. Meskipun ini bisa lebih mudah daripada memverifikasi identitas melalui jaringan kepercayaan, pengungkapan pengawasan massal 2013 membuatnya lebih dikenal luas bahwa otoritas sertifikat adalah titik lemah dari sudut pandang keamanan, yang memungkinkan [[serangan man-in-the-middle]] (MITM) jika otoritas sertifikat bekerja sama (atau dikompromikan).<ref>{{Cite web|url=https://www.eff.org/deeplinks/2010/03/researchers-reveal-likelihood-governments-fake-ssl|title=New Research Suggests That Governments May Fake SSL Certificates|last=Schoen|first=Seth|date=2010-03-24|website=Electronic Frontier Foundation|language=en|access-date=2020-05-30}}</ref>
== Algoritma ==
=== Pertukaran kunci atau perjanjian kunci ===
Sebelum klien dan server dapat mulai bertukar informasi yang dilindungi oleh TLS, mereka harus secara aman bertukar atau menyetujui kunci enkripsi dan cipher untuk digunakan saat mengenkripsi data. Di antara metode yang digunakan untuk pertukaran kunci / perjanjian adalah: kunci publik dan pribadi yang dihasilkan dengan RSA (dilambangkan TLS_RSA dalam protokol jabat tangan TLS), [[Diffie-Hellman]] (TLS_DH), ephemeral Diffie–Hellman (TLS_DHE), [[kurva elips Diffie-Hellman]] ( TLS_ECDH), kurva-elips epiferal Diffie-Hellman (TLS_ECDHE), [[Protokol perjanjian-kunci|Diffie-Hellman anonim]] (TLS_DH_anon), [[TLS-PSK|pre-shared key]] (TLS_PSK)<ref>{{Cite web|url=https://tools.ietf.org/html/rfc4279.html|title=Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)|last=Tschofenig|first=Hannes|last2=Eronen|first2=Pasi|website=tools.ietf.org|language=en|access-date=2020-05-30}}</ref> dan [[Secure Remote Password]] (TLS_SRP).<ref>{{Cite web|url=https://tools.ietf.org/html/rfc5054.html|title=Using the Secure Remote Password (SRP) Protocol for TLS Authentication|last=Perrin|first=Trevor|last2=Wu|first2=Tom|website=tools.ietf.org|language=en|access-date=2020-05-30|last3=Mavrogiannopoulos|first3=Nikos|last4=Taylor|first4=David}}</ref>
Metode perjanjian kunci TLS_DH_anon dan TLS_ECDH_anon tidak mengotentikasi server atau pengguna dan karenanya jarang digunakan karena mereka rentan terhadap [[serangan man-in-the-middle]]. Hanya TLS_DHE dan TLS_ECDHE yang memberikan kerahasiaan ke depan.
Sertifikat kunci publik yang digunakan selama pertukaran / perjanjian juga bervariasi dalam ukuran kunci enkripsi publik / swasta yang digunakan selama pertukaran dan karenanya ketahanan keamanan yang diberikan. Pada Juli 2013, [[Google]] mengumumkan bahwa mereka tidak akan lagi menggunakan kunci publik 1024-bit dan akan beralih ke kunci 2048-bit untuk meningkatkan keamanan enkripsi TLS yang diberikannya kepada penggunanya karena kekuatan enkripsi terkait langsung dengan ukuran kunci.<ref>{{Cite web|url=https://www.computing.co.uk/news/2285984/google-updates-ssl-certificates-to-2048bit-encryption|title=Google updates SSL certificates to 2048-bit encryption|date=2013-07-31|website=www.computing.co.uk|language=en|access-date=2020-05-30}}</ref>
{| class="wikitable" style="text-align:center"
|+ Pertukaran kunci / perjanjian dan otentikasi
! Algoritma !! SSL 2.0 !! SSL 3.0 !! TLS 1.0 !! TLS 1.1 !! TLS 1.2 !! TLS 1.3!! Status
|-
! {{Depends|[[RSA (cryptosystem)|RSA]]}}
| {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{N/A|No}} || rowspan="19"| Didefinisikan untuk TLS 1.2 dalam RFC
|-
!{{Depends|[[Diffie–Hellman key exchange|DH]]-[[RSA (cryptosystem)|RSA]]}}
| {{No}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{N/A|No}}
|-
!{{Good|[[Diffie–Hellman key exchange|DHE]]-[[RSA (cryptosystem)|RSA]] ([[#Forward secrecy|forward secrecy]])}}
| {{No}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}}
|-
!{{Depends|[[Elliptic-curve Diffie–Hellman|ECDH]]-[[RSA (cryptosystem)|RSA]]}}
| {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{Yes}} || {{N/A|No}}
|-
!{{Good|[[Elliptic-curve Diffie–Hellman|ECDHE]]-[[RSA (cryptosystem)|RSA]] ([[#Forward secrecy|forward secrecy]])}}
| {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}}
|-
!{{Depends|[[Diffie–Hellman key exchange|DH]]-[[Digital Signature Algorithm|DSS]]}}
| {{No}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{N/A|No}}
|-
!{{Good|[[Diffie–Hellman key exchange|DHE]]-[[Digital Signature Algorithm|DSS]] ([[#Forward secrecy|forward secrecy]])}}
| {{No}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{N/A|No}}<ref>{{cite web|url=https://www.ietf.org/mail-archive/web/tls/current/msg17680.html|title=Consensus: remove DSA from TLS 1.3|date=September 17, 2015|author=Sean Turner|url-status=live|archiveurl=https://web.archive.org/web/20151003193113/http://www.ietf.org/mail-archive/web/tls/current/msg17680.html|archivedate=October 3, 2015|df=}}</ref>
|-
!{{Depends|[[Elliptic-curve Diffie–Hellman|ECDH]]-[[Elliptic Curve DSA|ECDSA]]}}
| {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{Yes}} || {{N/A|No}}
|-
!{{Good|[[Elliptic-curve Diffie–Hellman|ECDHE]]-[[Elliptic Curve DSA|ECDSA]] ([[#Forward secrecy|forward secrecy]])}}
| {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}}
|-
!{{Depends|[[TLS-PSK|PSK]]}}
| {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{Yes}} ||
|-
!{{Depends|[[Pre-shared key|PSK]]-[[RSA (cryptosystem)|RSA]]}}
| {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{Yes}} ||
|-
!{{Good|[[Diffie–Hellman key exchange|DHE]]-[[Pre-shared key|PSK]] ([[#Forward secrecy|forward secrecy]])}}
| {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}}
|-
!{{Good|[[Elliptic-curve Diffie–Hellman|ECDHE]]-[[Pre-shared key|PSK]] ([[#Forward secrecy|forward secrecy]])}}
| {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}}
|-
!{{Depends|[[TLS-SRP|SRP]]}}
| {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{Yes}} ||
|-
!{{Depends|[[Secure Remote Password protocol|SRP]]-[[Digital Signature Algorithm|DSS]]}}
| {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{Yes}} ||
|-
!{{Depends|[[Secure Remote Password protocol|SRP]]-[[RSA (cryptosystem)|RSA]]}}
| {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{Yes}} ||
|-
!{{Depends|[[Kerberos (protokol)|Kerberos]]}}
| {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{Yes}} ||
|-
! {{Bad|[[Diffie–Hellman key exchange|DH]]-ANON (tidak aman)}}
| {{N/a|No}} || {{No|Yes}} || {{No|Yes}} || {{No|Yes}} || {{No|Yes}} ||
|-
! {{Bad|[[Elliptic-curve Diffie–Hellman|ECDH]]-ANON (tidak aman)}}
| {{N/a|No}} || {{N/a|No}} || {{No|Yes}} || {{No|Yes}} || {{No|Yes}} ||
|-
!{{Good|[[GOST|GOST R 34.10-94 / 34.10-2001]]<ref name=gostlink>[//tools.ietf.org/html/draft-chudov-cryptopro-cptls-04 draft-chudov-cryptopro-cptls-04 – GOST 28147-89 Cipher Suites for Transport Layer Security (TLS)]</ref>}}
| {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{Yes}} ||
| Diusulkan dalam konsep RFC
|}
== Dukungan untuk server virtual berbasis nama ==
Dari sudut pandang protokol aplikasi, TLS milik lapisan bawah, meskipun model TCP / IP terlalu kasar untuk menunjukkannya. Ini berarti bahwa jabat tangan TLS biasanya (kecuali dalam kasus [[TLS oportunistik|STARTTLS]]) dilakukan sebelum protokol aplikasi dapat dimulai. Dalam fitur [[Hosting virtual|server virtual berbasis nama]] yang disediakan oleh lapisan aplikasi, semua server virtual yang dihosting bersama berbagi sertifikat yang sama karena server harus memilih dan mengirim sertifikat segera setelah pesan ClientHello. Ini adalah masalah besar di lingkungan hosting karena itu berarti berbagi sertifikat yang sama di antara semua pelanggan atau menggunakan [[alamat IP]] yang berbeda untuk masing-masing pelanggan.
Ada dua solusi yang diketahui disediakan oleh [[X.509]]:
* Jika semua server virtual milik domain yang sama, sertifikat wildcard dapat digunakan.<ref>{{Cite web|url=https://ssl.comodo.com/wildcard-ssl-certificates|title=Wildcard SSL Certificates {{!}} What is a Wildcard Certificate?|website=ComodoCA Official Site|language=en|access-date=2020-05-31}}</ref> Selain pemilihan nama host longgar yang mungkin menjadi masalah atau tidak, tidak ada kesepakatan umum tentang cara mencocokkan sertifikat wildcard. Berbagai aturan diterapkan tergantung pada protokol aplikasi atau perangkat lunak yang digunakan.
* Tambahkan setiap nama host virtual di ekstensi subjectAltName. Masalah utama adalah bahwa sertifikat perlu diterbitkan kembali setiap kali server virtual baru ditambahkan.
Untuk memberikan nama server, Ekstensi RFC 4366 Transport Layer Security (TLS) memungkinkan klien untuk menyertakan [[ekstensi Indikasi Nama]] Server (SNI) dalam pesan ClientHello yang diperluas. Ekstensi ini mengisyaratkan ke server dengan segera nama yang ingin disambungkan klien, sehingga server dapat memilih sertifikat yang sesuai untuk dikirim ke klien.
== Standar ==
=== Standar primer ===
==== Versi TLS yang disetujui saat ini adalah versi 1.3, yang ditentukan dalam ====
*[[Rfc|RFC]] 8446: "Protokol Transport Layer Security (TLS) Versi 1.3".
==== Standar saat ini menggantikan versi sebelumnya, yang sekarang dianggap usang ====
*RFC 2246: "Protokol TLS Versi 1.0".
*RFC 4346: "Protokol Transport Layer Security (TLS) Versi 1.1".
*RFC 5246: "Protokol Transport Layer Security (TLS) Versi 1.2".
==== Serta SSL 2.0 dan 3.0 yang tidak pernah distandarisasi, yang dianggap usang ====
*[https://tools.ietf.org/html/draft-hickman-netscape-ssl-00 Internet Draft (1995)], SSL Versi 2.0
*RFC 6101: "Protokol Lapisan Soket Aman (SSL) Versi 3.0".
=== Extensi ===
RFC lain selanjutnya memperpanjang TLS.
==== Ekstensi ke TLS 1.0 meliputi ====
*RFC 2595: "Menggunakan TLS dengan IMAP, POP3 dan ACAP". Menentukan ekstensi ke layanan IMAP, POP3, dan ACAP yang memungkinkan server dan klien menggunakan keamanan lapisan transport untuk menyediakan komunikasi pribadi yang diautentikasi melalui Internet.
*RFC 2712: "Penambahan Suites [[Kerberos (protokol)|Kerberos]] Cipher ke Transport Layer Security (TLS)". Suite cipher 40-bit yang didefinisikan dalam memo ini hanya muncul untuk tujuan mendokumentasikan fakta bahwa kode-kode suite sandi tersebut telah ditetapkan.
*RFC 2817: "Memutakhirkan ke TLS dalam HTTP / 1.1", menjelaskan cara menggunakan mekanisme Upgrade dalam HTTP / 1.1 untuk memulai Transport Layer Security (TLS) melalui koneksi TCP yang ada. Ini memungkinkan lalu lintas HTTP yang tidak aman dan aman untuk berbagi port terkenal yang sama (dalam hal ini, http: di 80 daripada https: di 443).
*RFC 2818: "HTTP Over TLS", membedakan lalu lintas aman dari lalu lintas tidak aman dengan menggunakan 'port server' yang berbeda.
*RFC 3207: "Ekstensi Layanan SMTP untuk Mengamankan SMTP dari Keamanan Transport Layer". Menentukan ekstensi ke layanan SMTP yang memungkinkan server SMTP dan klien menggunakan keamanan lapisan transportasi untuk menyediakan komunikasi pribadi yang diautentikasi melalui Internet.
*RFC 3268: "AES Ciphersuites for TLS". Menambahkan cipher suites Standard Encryption Standard (AES) ke cipher simetris yang sudah ada sebelumnya.
*RFC 3546: "Ekstensi Transport Layer Security (TLS)", menambahkan mekanisme untuk menegosiasikan ekstensi protokol selama inisialisasi sesi dan mendefinisikan beberapa ekstensi. Dibuat usang oleh <nowiki>RFC 4366</nowiki>.
*RFC 3749: "Metode Kompresi Protokol Keamanan Lapisan Transportasi", menetapkan kerangka kerja untuk metode kompresi dan metode kompresi DEFLATE.
*RFC 3943: "Kompresi Protokol Transport Layer Security (TLS) Menggunakan Lempel-Ziv-Stac (LZS)".
*RFC 4132: "Penambahan Suites [[Camellia (sandi)|Camellia]] Cipher ke Transport Layer Security (TLS)".
* {{IETF RFC|4162}}: "Penambahan [[SEED]] Cipher Suites ke Transport Layer Security (TLS) ".
* {{IETF RFC|4217}}: "Mengamankan [[FTPS|FTP dengan TLS]] ".
* {{IETF RFC|4279}}: "Pre-Shared Key Ciphersuites untuk Transport Layer Security (TLS)", menambahkan tiga set suite cipher baru untuk protokol TLS untuk mendukung otentikasi berdasarkan kunci yang dibagikan sebelumnya.
'''Ekstensi ke TLS 1.1 meliputi:'''
* {{IETF RFC|4347}}: "Datagram Transport Layer Security "menentukan varian TLS yang berfungsi di atas protokol datagram (seperti UDP).
* {{IETF RFC|4366}}: "Ekstensi Transport Layer Security (TLS) "menjelaskan sekumpulan ekstensi spesifik dan mekanisme ekstensi umum.
* {{IETF RFC|4492}}: "Elliptic Curve Cryptography (ECC) Cipher Suites untuk Transport Layer Security (TLS) ".
* {{IETF RFC|4680}}: "Pesan Jabat Tangan TLS untuk Data Tambahan ".
* {{IETF RFC|4681}}: "Ekstensi Pemetaan Pengguna TLS ".
* {{IETF RFC|4785}}: "Ciphersuites Pra-Berbagi Kunci (PSK) dengan Enkripsi NULL untuk Transport Layer Security (TLS) ".
* {{IETF RFC|5054}}: "Menggunakan Protokol [[Kata sandi|Kata Sandi]] Jarak Jauh Aman (SRP) untuk Otentikasi TLS ". Mendefinisikan ciphersuites TLS-SRP.
* {{IETF RFC|5077}}: "Transisi Sesi Transport Layer Security (TLS) tanpa Status Sisi Server ".
* {{IETF RFC|5081}}: "Menggunakan Kunci OpenPGP untuk Otentikasi Transport Layer Security (TLS) ", usang oleh {{IETF RFC|6091}}.
'''Ekstensi ke TLS 1.2 meliputi:'''
* {{IETF RFC|5288}}: "Suite Cipher Suites Mode GES (GCM) untuk TLS ".
* {{IETF RFC|5289}}: "Suites TLS Elliptic Curve Cipher Suites dengan SHA-256/384 dan AES Galois Counter Mode (GCM)".
* {{IETF RFC|5746}}: "Perpanjangan Renegosiasi Indikasi Lapisan Transportasi (TLS)".
* {{IETF RFC|5878}}: "Ekstensi Otorisasi Keamanan Lapisan Transportasi (TLS) ".
* {{IETF RFC|5932}}: "Camellia Cipher Suites untuk TLS "
* {{IETF RFC|6066}}: "Ekstensi Transport Layer Security (TLS): Definisi Ekstensi ", termasuk Indikasi Nama Server dan stapel OCSP.
* {{IETF RFC|6091}}: "Menggunakan Kunci OpenPGP untuk Otentikasi Transport Layer Security (TLS) ".
* {{IETF RFC|6176}}: "Melarang Secure Sockets Layer (SSL) Versi 2.0 ".
* {{IETF RFC|6209}}: "Tambahan dari ARIA Cipher Suites ke Transport Layer Security (TLS) ".
* {{IETF RFC|6347}}: "Datagram Transport Layer Security Versi 1.2 ".
* {{IETF RFC|6367}}: "Penambahan Camellia Cipher Suites ke Transport Layer Security (TLS) ".
* {{IETF RFC|6460}}: "Suite B Profil untuk Transport Layer Security (TLS) ".
* {{IETF RFC|6655}}: "Suites Cipher AES-CCM untuk Transport Layer Security (TLS) ".
* {{IETF RFC|7027}}: "Kurva Elliptic Curve Cryptography (ECC) untuk Transport Layer Security (TLS) ".
* {{IETF RFC|7251}}: "Suite Cipher Elliptic Curve Cryptography (ECC) untuk TLS ".
* {{IETF RFC|7301}}: "Extensi Transport Layer Security (TLS) Application-Layer Protocol Negotiation".
* {{IETF RFC|7366}}: "Encrypt-then-MAC untuk Transport Layer Security (TLS) dan Datagram Transport Layer Security (DTLS) ".
* {{IETF RFC|7465}}: "Suites Cipher RC4 terlarang ".
* {{IETF RFC|7507}}: "Nilai TLS Fallback Signaling Cipher Suite (SCSV) untuk Mencegah Serangan Downgrade Protokol".
* {{IETF RFC|7568}}: "Deprecating Secure Sockets Layer Versi 3.0 ".
* {{IETF RFC|7627}}: "Transport Sesi Hash Lapisan Keamanan (TLS) dan Perpanjangan Master Secret ".
* {{IETF RFC|7685}}: Extensi "Client Layer Security (TLS) ClientHello Padding ".
'''Encapsulations of TLS include:'''
* {{IETF RFC|5216}}: "Protokol Otentikasi EAP-TLS "
*
== Referensi ==
{{Reflist|30em}}
{{FOLDOC}}
[[Kategori:Protokol kriptografi]]
[[
[[Kategori:Protokol lapisan presentasi]]
| |||