SSL / TLS 101 untuk Pemula

Pandangan mendalam pada enkripsi yang mengamankan koneksi internet kami


Meskipun Netscape awalnya menciptakan SSL pada pertengahan 90-an, Netscape tidak wajib bagi setiap situs web untuk menginstal sertifikat SSL / TLS hingga Musim Panas 2018 ketika Google mulai menandai situs yang tidak dienkripsi “Tidak Aman.”

Sementara Google – dengan mesin pencari, browser Chrome, dan Android OS – dapat mendefinisikan ulang internet secara sepihak, itu tidak sendirian dalam mandat ini. Apple, Microsoft, Mozilla dan pemangku kepentingan utama lainnya dalam industri teknologi semuanya telah membuat keputusan bersama untuk mengamanatkan sertifikat SSL / TLS dan HTTPS.

Alasannya sederhana: tanpa SSL / TLS dan kemampuan untuk terhubung dengan aman melalui HTTPS, semua komunikasi antara situs web dan pengunjung mereka akan dipertukarkan dalam plaintext dan mudah dibaca oleh pihak ketiga.

Satu-satunya downside ke dorongan baru-baru ini untuk enkripsi universal adalah bahwa ia memaksa masuknya pelanggan baru ke pasar yang tidak dikenal, pasar yang sangat sedikit membuat dirinya kurang membingungkan bagi rata-rata situs web atau pemilik bisnis.

Artikel ini akan berfungsi sebagai panduan komprehensif untuk semua hal SSL / TLS, kami akan meletakkan dasar dengan membahas konsep dasar seperti enkripsi, HTTPS dan sifat koneksi internet.

Semoga, pada akhirnya, Anda akan merasa yakin tentang memilih, membeli, dan menerapkan sertifikat TLS, dan ingat jika Anda memiliki pertanyaan yang dapat Anda tinggalkan di komentar di bawah.

Elemen Dasar

Mari kita mulai dengan membahas konsep yang menjadi inti dari semua ini: enkripsi.

Enkripsi, dalam iterasi yang paling mudah, tidak lebih dari pengacakan data – menggunakan sandi atau kunci yang telah ditentukan – sehingga tidak dapat dibaca oleh siapa pun kecuali pihak lain dengan kunci pribadi yang sama.

Sepanjang sejarah, enkripsi kunci pribadi telah menjadi model yang paling umum digunakan. Dalam enkripsi kunci pribadi, kedua belah pihak harus memiliki atau setidaknya bertukar kunci pribadi yang dapat digunakan untuk mengenkripsi dan mendekripsi informasi.

Sejak awal, sebagian besar cipher yang menopang cryptosystems ini primitif, mengandalkan substitusi sederhana atau mengganti kata-kata umum dengan karakter. Namun seiring waktu cipher menjadi lebih dipengaruhi oleh matematika dan tumbuh dalam kompleksitas.

Sebagai contoh, pada pertengahan 1600-an di Perancis, kriptografi Raja Louis XIV menciptakan sandi yang dirancang dengan sangat baik sehingga tidak rusak hingga 250 tahun kemudian dan baru sebagian. Hingga hari ini ada catatan ratusan tahun di arsip Prancis yang mungkin tidak pernah diuraikan.

Tapi sementara enkripsi secara historis telah menjadi sarana untuk menjadi rahasia atau klandestin, munculnya internet telah mengambil konsep yang lebih utama. Internet ada di mana-mana, dan menangani berbagai fungsi penting. Setiap hari milyaran orang menggunakannya untuk mengakses dan mengirim informasi sensitif, mengelola keuangan mereka, bertransaksi dengan bisnis — sebut saja.

Masalahnya adalah bahwa internet tidak sepenuhnya dirancang untuk mengukur apa yang telah terjadi. Awalnya, pada hari-hari ketika akademisi dan pemerintah AS pertama kali mengembangkan protokol jaringan, internet hanya dilihat sebagai mekanisme pertukaran informasi secara bebas antara pemerintah dan lembaga akademik. Pada saat itu, aktivitas komersial adalah ilegal secara online. eCommerce bukanlah kata yang bahkan telah ditemukan. Dan situs web lebih merupakan gagasan geografis.

Jadi, ketika HTTP atau Hypertext Transfer Protocol pertama kali diperkenalkan pada tahun 1991, fakta bahwa koneksi yang dibentuknya dipertukarkan data dalam plaintext bukan masalah yang mendiskualifikasi.

Semuanya jauh berbeda hari ini. Informasi yang dipertukarkan online bukanlah penelitian akademis atau informasi yang tersedia secara bebas, itu adalah informasi yang dapat diidentifikasi secara pribadi dan data sensitif yang dapat membuat orang kehilangan uang atau bahkan, di beberapa wilayah, kehidupan mereka. Ini membutuhkan pendekatan yang lebih aman.

Jawabannya adalah enkripsi.

Masalah bertukar kunci

Satu masalah yang secara historis menjangkiti bahkan cryptosystems terbaik terus bertahan hingga hari ini.

Apa yang kita diskusikan sebelumnya, dan apa yang secara tradisional menjadi standar untuk enkripsi, adalah enkripsi kunci pribadi. Ini juga disebut enkripsi simetris, atau enkripsi dua arah — dengan kunci pribadi yang menangani fungsi enkripsi dan dekripsi yang diperlukan untuk berkomunikasi.

Agar enkripsi kunci pribadi berfungsi, kunci pribadi harus ditransfer antar pihak, atau kedua belah pihak harus memiliki salinannya sendiri. Either way, keamanan kunci pribadi sangat penting untuk integritas cryptosystem dan, seperti yang Anda duga, pertukaran kunci adalah masalah setua enkripsi itu sendiri.

Kemudian, pada 1970-an – secara teknis dua kali berbeda, seluruh samudera terpisah – bentuk enkripsi baru dikonseptualisasikan dan dihidupkan: enkripsi kunci publik.

Sementara enkripsi kunci privat adalah fungsi dua arah, simetris, dengan kunci privat yang mampu mengenkripsi dan mendekripsi data, enkripsi kunci publik bersifat asimetris; satu arah. Daripada satu kunci pribadi, ada pasangan kunci publik-swasta. Kunci publik menangani enkripsi dan, seperti namanya, tersedia untuk umum sementara kunci pribadi, yang menangani dekripsi, dirahasiakan oleh pemiliknya. Dengan menggunakan kunci publik, seseorang dapat mengenkripsi sepotong data dan mengirimkannya ke pemilik kunci, di mana hanya mereka yang akan dapat mendekripsi..

Bagus, tapi bagaimana itu berguna?

Enkripsi satu arah tidak ideal untuk mengenkripsi koneksi internet, agak sulit untuk berkomunikasi ketika satu pihak hanya dapat mengenkripsi, dan yang lainnya hanya dapat mendekripsi. Tidak, untuk mengenkripsi koneksi internet, Anda harus menggunakan enkripsi kunci privat simetris.

Tapi bagaimana Anda bertukar kunci? Terutama online?

Enkripsi kunci publik.

Dan itu, disaring sampai ke intinya, adalah apa yang SSL / TLS adalah tentang: pertukaran kunci aman.

Di sinilah kami akan mengikat semua konsep ini bersama-sama. Jika Anda ingin komunikasi Anda dengan situs web menjadi pribadi, maka Anda harus terhubung dengan aman. Jika Anda ingin terhubung dengan aman dengan situs web itu, maka Anda perlu bertukar kunci privat simetris sehingga Anda dapat menggunakannya untuk berkomunikasi. SSL / TLS (dan PKI secara umum) hanyalah mekanisme yang bagus untuk membuat dan menukar kunci sesi itu.

Menggunakan SSL / TLS, Anda dapat mengotentikasi server atau organisasi yang akan terhubung dengan Anda dan memastikan bahwa Anda secara aman bertukar kunci pribadi yang akan Anda gunakan untuk mengenkripsi komunikasi Anda dengan pihak yang dimaksud.

Sayangnya, SSL / TLS dan PKI memiliki banyak terminologi dan bagian yang bergerak yang dapat dengan mudah membingungkan orang, tetapi mereka percaya fakta bahwa ketika Anda menghapus semua matematika dan jargon teknis, ini hanyalah solusi teknologi modern yang elegan untuk zaman ini. masalah lama: pertukaran kunci.

Sekarang mari kita membahas beberapa istilah kunci

Sebelum kita melangkah lebih jauh, mari kita membahas beberapa istilah kunci lainnya. Kami telah memperkenalkan HTTP, protokol transfer hiperteks, yang telah menjadi tulang punggung internet selama beberapa dekade. Tapi seperti yang kita bahas, internet berkembang menjadi sesuatu yang jauh berbeda dari ketika HTTP pertama kali diterbitkan pada tahun 1991.

Diperlukan protokol yang lebih aman. Demikian HTTPS.

HTTPS, yang kadang-kadang disebut sebagai HTTP over TLS, menggunakan enkripsi untuk membuat data yang dipertukarkan selama koneksi tidak dapat dibaca oleh siapa pun kecuali pihak yang dituju. Ini sangat penting ketika Anda mempertimbangkan sifat koneksi internet modern.

Sedangkan pada hari-hari awal internet koneksi itu cukup langsung, sekarang koneksi dialihkan melalui puluhan perangkat dalam perjalanan ke tujuan akhir mereka. Jika Anda pernah menginginkan demonstrasi praktis ini, buka command prompt pada OS Anda dan masukkan perintah “tracert geekflare.com.”

Apa yang akan Anda lihat adalah jalur yang dilalui koneksi Anda dalam perjalanan ke tujuannya. Hingga 30 lompatan. Itu berarti bahwa data Anda melewati masing-masing perangkat tersebut sebelum mencapai situs web atau aplikasi apa pun yang Anda sambungkan. Dan jika ada yang memiliki sniffer paket atau beberapa pendengar yang diinstal pada salah satu perangkat itu, mereka dapat mencuri data yang dikirim dan bahkan memanipulasi koneksi dalam beberapa kasus.

Ini disebut serangan man-in-the-middle (MITM).

Jika Anda ingin belajar tentang serangan MITM, maka lihat kursus online ini.

Ada lebih banyak area permukaan untuk ditutupi dengan koneksi internet modern daripada yang disadari oleh sebagian besar orang, itulah mengapa memiliki data yang dienkripsi selama transmisi sangat penting. Anda tidak tahu siapa yang bisa mendengarkan, atau betapa mudahnya melakukannya.

Koneksi HTTP dibuat melalui port 80. Untuk tujuan kami, Anda dapat menganggap port sebagai konstruksi yang menunjukkan layanan atau protokol jaringan. Situs web standar yang dilayani melalui HTTP menggunakan port 80. HTTPS biasanya menggunakan port 443. Ketika situs web menginstal sertifikat, ia dapat mengalihkan halaman HTTP-nya ke HTTPS, dan browser pengguna akan berusaha untuk terhubung dengan aman melalui port 443, menunggu otentikasi.

Sayangnya, istilah SSL / TLS, HTTPS, PKI, dan enkripsi semuanya sering digunakan, kadang-kadang bahkan digunakan secara bergantian, sehingga untuk menghilangkan kebingungan yang masih ada, inilah panduan singkatnya:

  • SSL – Secure Sockets Layer, protokol enkripsi asli yang digunakan dengan HTTPS
  • TLS – Transport Layer Security, protokol enkripsi yang lebih baru yang telah menggantikan SSL
  • HTTPS – Versi HTTP yang aman, digunakan untuk membuat koneksi dengan situs web
  • PKI – Infrastruktur Kunci Publik, mengacu pada seluruh model kepercayaan yang memfasilitasi enkripsi kunci publik

SSL / TLS bekerja bersama untuk mengaktifkan koneksi HTTPS. Dan PKI mengacu pada semuanya saat Anda memperkecil.

Oke? Jangan khawatir, Anda akan melakukannya.

Membangun Infrastruktur Kunci Publik

Sekarang kita telah meletakkan fondasi, mari perkecil dan lihat arsitektur yang digunakan oleh model kepercayaan di jantung SSL / TLS.

Ketika Anda tiba di sebuah situs web, hal pertama yang dilakukan browser Anda adalah memverifikasi keaslian sertifikat SSL / TLS yang disajikan oleh situs tersebut. Kami akan membahas apa yang terjadi setelah otentikasi berlangsung di beberapa bagian, tetapi kami akan mulai dengan membahas model kepercayaan yang memungkinkan semua ini terjadi..

Jadi, kita akan mulai dengan mengajukan pertanyaan: bagaimana komputer saya tahu apakah akan mempercayai sertifikat SSL / TLS yang diberikan?

Untuk menjawab itu, kita perlu membahas PKI dan berbagai elemen yang membuatnya bekerja. Kami akan mulai dengan Program Otoritas Sertifikat dan Root.

Otoritas Sertifikat

Otoritas Sertifikat adalah organisasi yang mematuhi serangkaian standar yang telah ditentukan sebagai imbalan atas kemampuan untuk menerbitkan sertifikat digital tepercaya.

Ada puluhan CA, baik gratis maupun komersial, yang dapat menerbitkan sertifikat tepercaya.

Mereka semua harus mematuhi serangkaian standar yang telah diperdebatkan dan disahkan melalui CA / Forum Peramban, yang bertindak sebagai badan pengatur untuk industri TLS. Standar-standar ini menguraikan hal-hal seperti:

  • Perlindungan teknis yang harus ada
  • Praktik terbaik untuk melakukan validasi
  • Penerbitan praktik terbaik
  • Prosedur dan jadwal pencabutan
  • Persyaratan Pencatatan Sertifikat

Panduan ini telah ditetapkan oleh browser, bersama dengan CA. Browser memainkan peran unik dalam ekosistem TLS.

Tidak ada yang bisa mendapatkan apa pun di internet tanpa browser web mereka. Dengan demikian, browserlah yang akan menerima dan memvalidasi sertifikat TLS digital dan kemudian bertukar kunci dengan server. Jadi, mengingat peran terpenting mereka, mereka memiliki pengaruh yang besar.

Dan penting untuk diingat bahwa browser telah dirancang untuk menjadi sesesat mungkin. Untuk tidak percaya apa pun. Ini adalah cara terbaik untuk menjaga keamanan penggunanya. Jadi, jika peramban akan mempercayai sertifikat digital – yang berpotensi dapat disalahgunakan sehingga merugikan pengguna – itu memerlukan jaminan tertentu bahwa siapa pun yang mengeluarkan sertifikat ini melakukan uji tuntas mereka..

Ini adalah peran dan tanggung jawab Otoritas Sertifikat. Dan browser juga tidak melakukan kesalahan. Ada kuburan harfiah dari mantan CA yang telah bertabrakan dengan browser dan dikeluarkan untuk padang rumput.

Ketika Otoritas Sertifikat telah menunjukkan kepatuhannya dengan persyaratan dasar Forum CAB dan telah melewati semua audit dan ulasan yang dipersyaratkan, ia dapat mengajukan petisi ke berbagai program root untuk menambahkan sertifikat Root-nya..

Program Rooting

Program root – yang utama dijalankan oleh Apple, Microsoft, Google, dan Mozilla – adalah aparatur yang mengawasi dan memfasilitasi toko root (kadang-kadang disebut toko simpanan), yang merupakan kumpulan sertifikat CA Root yang berada di sistem pengguna. Sekali lagi, akar-akar ini sangat berharga dan sangat berbahaya – mereka dapat mengeluarkan sertifikat digital tepercaya – sehingga keamanan menjadi perhatian utama.

Itu sebabnya CA hampir tidak pernah mengeluarkan langsung dari sertifikat Root CA sendiri. Sebagai gantinya, mereka meningkatkan sertifikat root perantara dan menggunakannya untuk mengeluarkan sertifikat pengguna akhir atau daun. Mereka juga dapat menyerahkan root tersebut ke Sub-CA, yang merupakan Otoritas Sertifikat yang tidak memiliki akar khusus tetapi masih dapat mengeluarkan sertifikat yang ditandatangani secara silang dari perantara mereka..

Jadi, mari kita selesaikan semuanya. Ketika situs web ingin memiliki sertifikat TLS yang diterbitkan, situs web ini menghasilkan sesuatu yang disebut Permintaan Penandatanganan Sertifikat (CSR) di server tempat hostingnya. Yang terkandung dalam permintaan ini adalah semua detail yang ingin dimasukkan oleh situs web pada sertifikat. Seperti yang akan Anda lihat sedikit, jumlah informasi dapat bervariasi dari detail bisnis lengkap hingga identitas server yang sederhana, tetapi begitu CSR selesai, itu dikirim bersama ke Otoritas Sertifikat untuk diterbitkan.

Sebelum menerbitkan sertifikat, CA harus melakukan uji tuntas yang dimandatkan CA / Browser dan memvalidasi bahwa informasi yang terkandung dalam CSR akurat. Setelah diverifikasi, ia menandatangani sertifikat dengan kunci pribadi dan mengirimkannya kembali ke pemilik situs web untuk instalasi.

Sertifikat Chaining

Setelah sertifikat TLS diinstal, kapan pun seseorang mengunjungi situs yang dihosting, server itu akan memberikan sertifikat kepada browser pengguna. Peramban akan melihat tanda tangan digital pada sertifikat, yang dibuat oleh otoritas sertifikat tepercaya, yang menjamin fakta bahwa semua informasi yang terkandung dalam sertifikat itu akurat.

Di sinilah istilah rantai sertifikat mulai berlaku.

Browser akan membaca tanda tangan digital dan memindahkan tautan pada rantai — selanjutnya, ia akan memeriksa tanda tangan digital pada sertifikat perantara yang kunci pribadinya digunakan untuk menandatangani sertifikat daun. Itu akan terus mengikuti tanda tangan sampai rantai sertifikat berakhir di salah satu root tepercaya di root store, atau sampai rantai berakhir tanpa mencapai root, dalam hal ini kesalahan browser akan muncul, dan koneksi akan gagal.

Inilah sebabnya Anda tidak dapat mengeluarkan dan menandatangani sendiri sertifikat Anda.

Browser hanya akan mempercayai sertifikat SSL / TLS yang dapat mereka rantai kembali ke root store (artinya dikeluarkan oleh entitas tepercaya). Otoritas Sertifikat diharuskan untuk mematuhi standar khusus untuk mempertahankan kepercayaan mereka, dan bahkan browser pun enggan untuk mempercayai mereka..

Peramban tidak memiliki jaminan semacam itu tentang sertifikat yang ditandatangani sendiri, itulah sebabnya mengapa mereka hanya boleh digunakan di jaringan internal, di belakang firewall, dan di lingkungan pengujian.

Tipe dan Fungsi Sertifikat SSL / TLS

Sebelum kita melihat SSL / TLS yang sedang bergerak, mari kita bicara tentang sertifikat dan berbagai iterasi yang tersedia. Sertifikat TLS adalah apa yang memfasilitasi protokol TLS dan membantu menentukan ketentuan koneksi HTTPS terenkripsi yang dibuat oleh suatu situs web.

Sebelumnya kami telah menyebutkan bahwa memasang sertifikat TLS memungkinkan Anda untuk mengonfigurasi situs web Anda untuk membuat koneksi HTTPS melalui port 443. Ia juga bertindak sebagai semacam badge nama untuk situs atau server yang berinteraksi dengan Anda. Kembali ke gagasan bahwa pada intinya, SSL / TLS dan PKI adalah semua bentuk pertukaran kunci aman yang sangat baik, sertifikat SSL / TLS membantu memberi tahu peramban tentang siapa yang mengirim kunci sesi kepada — kepada siapa pihak di ujung koneksinya adalah.

Dan ketika Anda memecah berbagai iterasi sertifikat SSL / TLS, itu hal yang perlu diingat. Sertifikat bervariasi mengenai fungsionalitas dan tingkat validasi. Atau dengan kata lain, mereka berbeda berdasarkan:

  • Berapa banyak identitas yang harus ditegaskan
  • Apa tujuan akhir untuk menegaskan identitas

Menjawab dua pertanyaan itu akan memberi Anda indikasi yang cukup jelas tentang jenis sertifikat apa yang Anda butuhkan.

Berapa banyak identitas untuk Menyatakan

Ada tiga tingkat validasi yang tersedia dengan sertifikat SSL / TLS, dan mereka bervariasi berdasarkan pada seberapa banyak informasi identitas yang ingin ditegaskan oleh situs web Anda.

  • Validasi Domain Sertifikat SSL – Menegaskan identitas server
  • Validasi Organisasi Sertifikat SSL – Menegaskan identitas organisasi sebagian
  • Validasi Diperpanjang Sertifikat SSL – Menegaskan identitas organisasi lengkap

Validasi Domain Sertifikat SSL sejauh ini paling populer karena harganya dan kecepatan mengeluarkannya. Sertifikat DV SSL / TLS memerlukan pemeriksaan kontrol domain sederhana, yang dapat dilakukan dengan beberapa cara berbeda, tetapi segera setelah sertifikat dikeluarkan, sertifikat dapat dikeluarkan. Anda juga bisa mendapatkan versi 30 hari dan 90 hari ini secara gratis, yang tidak diragukan lagi telah menambah pangsa pasar mereka.

Kelemahannya adalah bahwa sertifikat DV SSL menegaskan identitas minimal. Dan mengingat bahwa hampir setengah dari semua situs web phishing sekarang memiliki sertifikat DV SSL yang diinstal pada mereka, mereka tidak selalu membeli Anda banyak dalam cara kepercayaan.

Validasi Organisasi Sertifikat SSL adalah jenis asli dari sertifikat SSL / TLS. Mereka juga satu-satunya jenis sertifikat SSL yang dapat mengamankan alamat IP setelah keputusan 2016 oleh CAB Forum untuk membatalkan semua sertifikat SSL intranet. Validasi Organisasi membutuhkan pemeriksaan bisnis ringan dan biasanya dapat dikeluarkan dalam satu atau dua hari — terkadang lebih cepat. Sertifikat OV SSL menyatakan beberapa informasi organisasi, tetapi pengguna internet perlu mengklik ikon gembok dan mencarinya. Saat ini Anda melihat banyak sertifikat SSL OV yang digunakan pada jaringan perusahaan dan perusahaan besar, untuk koneksi yang dibuat di belakang firewall misalnya.

Karena baik sertifikat DV maupun OV SSL tidak menyatakan identitas yang memadai untuk memenuhi sebagian besar browser, mereka menerima perlakuan netral.

Validasi Diperpanjang Sertifikat SSL sejauh ini merupakan yang paling kontroversial, karena beberapa komunitas teknologi merasa lebih perlu dilakukan untuk memperkuat validasi yang menjadi sandaran mereka. Namun, EV SSL menegaskan identitas maksimum. Untuk menyelesaikan validasi yang diperpanjang, Otoritas Sertifikat menempatkan organisasi melalui proses pemeriksaan ketat yang dapat memakan waktu hingga seminggu dalam beberapa kasus.

Tetapi manfaatnya tidak dapat dipungkiri: karena menegaskan identitas yang cukup, situs web dengan sertifikat EV SSL menerima perlakuan browser yang unik, termasuk menampilkan namanya di bilah alamat browser.

Tidak ada cara lain untuk mencapai ini, dan Anda tidak bisa memalsukannya — bilah alamat EV adalah salah satu indikator visual paling ampuh yang kita miliki saat ini.

Apa tujuan akhir untuk menyatakan Identitas pada

Cara lain yang berbeda dari sertifikat SSL / TLS adalah mengenai fungsionalitas. Situs web telah berkembang sedikit sejak awal internet dengan berbagai perusahaan menyebarkan situs dengan cara yang berbeda. Beberapa memiliki beberapa domain untuk berbagai vertikal perusahaan; yang lain menggunakan sub-domain untuk berbagai fungsi dan aplikasi web. Beberapa menggunakan keduanya.

Apa pun konteksnya, ada sertifikat SSL / TLS yang dapat membantu mengamankannya.

Domain tunggal

Situs web utama dan sertifikat SSL standar hanya satu domain. Sebagian besar sertifikat SSL / TLS modern akan mengamankan versi WWW dan non-WWW dari domain itu, tetapi terbatas pada satu domain. Kamu bisa bandingkan sertifikat SSL di sini.

Multi-Domain

Sertifikat multi-Domain atau Sertifikat Komunikasi Terpadu (dalam hal server Microsoft Exchange dan Office Communications) juga ada untuk memberi organisasi kemampuan untuk mengenkripsi beberapa domain dengan satu sertifikat. Ini bisa menjadi pilihan yang menarik karena menghemat uang dan itu membuat mengelola sertifikat (kedaluwarsa / pembaruan) jauh lebih mudah.

Sertifikat Multi-Domain dan UCC menggunakan SAN, bidang Nama Alternatif Subjek dalam CSR, untuk menambahkan domain tambahan ke sertifikat. Sebagian besar CA memungkinkan hingga 250 SAN yang berbeda pada satu sertifikat. Dan sebagian besar sertifikat Multi-Domain dilengkapi dengan 2-4 SAN gratis dengan sisanya tersedia untuk pembelian sesuai kebutuhan.

Sertifikat SSL wildcard

Sertifikat SSL wildcard adalah jenis sertifikat yang sangat berguna karena mereka dapat mengenkripsi sub-domain dalam jumlah yang tidak terbatas pada tingkat URL yang sama. Misalnya, jika Anda memiliki situs web yang menggunakan sub-domain seperti:

  • app.website.com
  • portal.website.com
  • user.website.com

Anda dapat mengenkripsi semuanya dengan sertifikat Wildcard yang sama dengan menggunakan tanda bintang di bidang FQDN CSR Anda: * .website.com

Sekarang setiap sub-domain, bahkan yang belum Anda tambahkan, dapat diamankan dengan sertifikat itu.

Ada dua kelemahan untuk sertifikat Wildcard. Yang pertama adalah bahwa dengan menggunakan kunci publik yang sama di beberapa titik akhir, Anda lebih rentan terhadap eksploitasi tertentu seperti serangan Bleichenbacher.

Yang lainnya adalah tidak ada opsi EV Wildcard. Karena sifat fungsionalitas Wildcard yang terbuka, browser tidak OK dengan mendelegasikan mereka pada tingkat kepercayaan. Jika Anda ingin Bilah Alamat EV di sub-domain Anda, Anda harus mengenkripsi mereka secara individual atau menggunakan sertifikat Multi-Domain EV.

Wildcard Multi-Domain

Tambahan yang relatif baru untuk ekosistem SSL / TLS, Multi-Domain Wildcard dapat mengenkripsi hingga 250 domain yang berbeda, tetapi juga dapat menggunakan tanda bintang di bidang SAN, yang juga memungkinkan Anda untuk mengenkripsi 250 domain yang berbeda DAN semua yang menyertainya terlebih dahulu -tingkat sub-domain.

Kegunaan lain untuk Multi-Domain Wildcard adalah sebagai Wildcard multi-level, di mana ia dapat mengenkripsi sub-domain pada berbagai level URL (Wildcard standar hanya dapat mengenkripsi mereka pada satu level).

Karena fungsi Wildcard, Multi-Domain Wildcard juga tidak tersedia di EV.

SSL / TLS dalam Gerakan

Sekarang kita telah membahas semua konsep penting yang membentuk SSL / TLS dan PKI, mari kita satukan semuanya dan melihatnya bergerak.

Validasi dan Penerbitan

Mari kita mulai dari awal dengan situs web yang membeli sertifikat SSL / TLS dari CA atau pengecer. Setelah pembelian, kontak organisasi yang menangani perolehan sertifikat membuat Permintaan Penandatanganan Sertifikat di server tempat sertifikat akan dipasang (server yang menghosting situs web).

Seiring dengan CSR, server juga akan menghasilkan pasangan kunci publik / pribadi dan menyimpan kunci pribadi secara lokal. Ketika CA menerima CSR dan Kunci Publik, CA melakukan langkah-langkah validasi yang diperlukan untuk memastikan bahwa segala informasi yang terkandung dalam sertifikat itu akurat. Secara umum, untuk sertifikat autentikasi bisnis (bukan DV) ini melibatkan pencarian informasi pendaftaran dan catatan publik organisasi dalam basis data pemerintah.

Setelah validasi selesai, CA menggunakan salah satu kunci pribadi dari salah satu sertifikat yang diterbitkannya, biasanya root perantara, dan menandatangani sertifikat sebelum mengembalikannya ke pemilik situs..

Sekarang pemilik situs web dapat mengambil sertifikat SSL / TLS yang baru dikeluarkan, menginstalnya di server mereka dan mengkonfigurasi situs web untuk membuat koneksi HTTPS pada port 443 (menggunakan 301 redirect untuk mengirim lalu lintas dari halaman HTTP yang sudah ada sebelumnya ke rekan HTTPS baru mereka).

Otentikasi dan Jabat Tangan SSL

Sekarang setelah sertifikat SSL / TLS diinstal, dan situs web telah dikonfigurasi untuk HTTPS, mari kita lihat bagaimana hal itu akan memfasilitasi koneksi terenkripsi dengan pengunjung situs.

Setelah tiba di situs web, server akan menyajikan sertifikat SSL / TLS ke browser pengguna. Browser pengguna kemudian melakukan serangkaian pemeriksaan.

Pertama, itu akan mengotentikasi sertifikat dengan melihat tanda tangan digitalnya dan mengikuti rantai sertifikat. Ini juga akan memastikan sertifikat belum kedaluwarsa dan memeriksa log Transparansi Sertifikat (CT) dan Daftar Pencabutan Sertifikat (CRL). Asalkan rantai mengarah kembali ke salah satu akar di trust store sistem, dan valid, browser akan mempercayai sertifikat.

Sekarang saatnya berjabat tangan.

Jabat tangan SSL / TLS adalah serangkaian langkah di mana klien (pengguna) dan server (situs web) menegosiasikan parameter koneksi aman mereka, menghasilkan dan kemudian bertukar kunci sesi simetris.

Pertama, mereka akan memutuskan paket sandi. Suite sandi adalah grup algoritma dan sandi yang akan digunakan untuk koneksi. Sertifikat SSL / TLS menyediakan daftar suite sandi yang didukung server. Secara umum, rangkaian sandi mencakup algoritma enkripsi kunci publik, algoritma pembuatan kunci, algoritma otentikasi pesan, dan algoritma enkripsi simetris atau massal — meskipun telah disempurnakan dalam TLS 1.3.

Setelah diberi daftar cipher yang didukung, klien akan memilih yang disetujui dan mengkomunikasikannya ke server. Dari sana, klien akan menghasilkan kunci sesi simetris, mengenkripsi menggunakan kunci publik dan kemudian mengirimkannya ke server, yang memiliki kunci pribadi yang diperlukan untuk mendekripsi kunci sesi.

Setelah kedua belah pihak memiliki salinan kunci sesi, komunikasi dapat dimulai.

Dan itu SSL / TLS.

Anda dapat melihat bagaimana semua konsep yang kami lalui sebelumnya berinteraksi satu sama lain untuk menciptakan sistem yang canggih namun elegan untuk mengamankan koneksi internet. Kami menggunakan kriptografi kunci publik untuk bertukar kunci sesi dengan aman yang akan kami komunikasikan. Sertifikat yang menyatakan identitas server atau organisasi dapat dipercaya karena infrastruktur yang kami miliki antara berbagai CA, browser, dan program root.

Dan komunikasi terjadi sebagai hasil dari enkripsi kunci privat simetris dan turunan dari cryptosystems klasik jaman dahulu..

Ada banyak bagian yang bergerak, tetapi ketika Anda memperlambat dan memahaminya secara individual, jauh lebih mudah untuk melihat bagaimana semuanya bekerja bersama..

Sebelum Anda pergi, mari kita selesaikan dengan beberapa langkah terkait SSL / TLS Anda dapat melakukan post-instalasi / konfigurasi untuk mendapatkan hasil maksimal dari investasi Anda.

Setelah SSL / TLS – Mendapatkan hasil maksimal dari implementasi Anda

Hanya dengan memasang sertifikat dan mengonfigurasi situs web dengan benar, bukan berarti situs web Anda aman. TLS hanyalah salah satu komponen dari strategi pertahanan dunia maya yang lebih luas dan holistik. Namun komponen yang penting, tetap saja. Mari kita bahas beberapa hal yang dapat Anda lakukan untuk memastikan bahwa Anda mendapatkan hasil maksimal dari implementasi.

Nonaktifkan dukungan server untuk protokol lama

Menggandakan kembali ke percakapan kami sebelumnya tentang Cipher Suites, bagian dari mengkonfigurasi server Anda adalah memutuskan suite cipher dan SSL / TLS versi apa yang akan didukung. Sangat penting bahwa Anda menonaktifkan dukungan untuk versi SSL / TLS yang lebih lama serta algoritma khusus untuk mencegah kerentanan terhadap beberapa eksploitasi yang diketahui.

SSL 2.0 dan SSL 3.0 berusia di atas 20 tahun. Praktik terbaik adalah mencabut dukungan untuk mereka bertahun-tahun yang lalu, tetapi sampai hari ini sekitar 7% dari 100.000 teratas Alexa masih memungkinkan mereka. Ini berbahaya karena membuat Anda terkena serangan stripping dan downgrade SSL seperti POODLE.

TLS 1.0 dan TLS 1.1 juga dipinjam waktu.

Perusahaan teknologi besar, Apple, Microsoft, Google, dan Mozilla, membuat pengumuman bersama pada musim gugur ini bahwa mereka akan mencabut dukungan untuk TLS 1.0 dan 1.1 pada awal 2020.

Versi protokol rentan terhadap kerentanan seperti POODLE, FREAK, BEAST, dan CRIME (ini semua adalah akronim). TLS 1.2 telah keluar selama sepuluh tahun dan harus menjadi standar. TLS 1.3 diselesaikan pada musim panas lalu dan adopsi telah bergerak dengan kecepatan yang stabil sejak itu.

Selain itu, ada algoritma khusus yang tidak boleh digunakan. DES, misalnya, dapat dipecahkan dalam hitungan jam. RC4 lebih rentan daripada yang diyakini sebelumnya dan telah dilarang oleh Standar Keamanan Data Industri Kartu Pembayaran. Dan akhirnya, mengingat berita tentang eksploitasi baru-baru ini, tidak disarankan untuk menggunakan RSA untuk pertukaran kunci lagi.

Algoritma / cipher yang disarankan:

  • Pertukaran Kunci: Elliptic Curie Diffie-Helman (ECDH)
  • Otentikasi: Elliptic Curve Digital Signature Algorithm (ECDSA)
  • Enkripsi Simetris / Massal: AES 256 dalam Mode Penghitung Galois (AES256-GCM)
  • Algoritma MAC: SHA-2 (SHA384)

SSL selalu aktif

Di masa lalu, situs web terkadang hanya memigrasikan halaman web yang mengumpulkan informasi ke HTTPS, sembari melayani situs lainnya melalui HTTP. Ini adalah praktik yang buruk.

Selain fakta bahwa Google akan menandai halaman-halaman itu “Tidak Aman,” Anda juga berpotensi mengekspos pengunjung situs Anda pada risiko dengan membuat browser mereka bolak-balik antara halaman terenkripsi dan yang HTTP..

Anda harus mengonfigurasi seluruh situs web Anda untuk HTTPS. Ini disebut SSL Selalu Aktif. Lagi pula, ini tidak seperti Anda membayar berdasarkan halaman, sertifikat SSL / TLS Anda dapat mengenkripsi seluruh situs Anda. Jadi buatlah begitu.

Menyiapkan Catatan Otoritas Otoritas Sertifikat (CAA)

Salah satu risiko paling signifikan yang ditimbulkan oleh sertifikat digital, secara umum, adalah kesalahan penerbitan. Jika pihak selain Anda mendapatkan sertifikat SSL / TLS untuk situs web ANDA, mereka dapat secara efektif menyamar sebagai Anda dan menyebabkan semua jenis masalah.

Catatan CAA membantu mengurangi risiko ini dengan membatasi apa yang Otoritas Sertifikat dapat mengeluarkan sertifikat digital untuk situs web Anda. Otoritas Sertifikat diperlukan oleh CA / Forum Peramban untuk memeriksa catatan CAA sebelum mengeluarkan sertifikat apa pun. Jika CA tidak memiliki otorisasi untuk menerbitkan situs tersebut, CA tidak dapat melakukannya. Melakukan hal itu akan dianggap sebagai salah penerbitan dan mengumpulkan kemarahan komunitas browser.

Menambahkan catatan CAA relatif mudah, ini adalah catatan DNS sederhana yang dapat ditambahkan melalui antarmuka sebagian besar platform hosting. Anda dapat membatasi CA yang mungkin mengeluarkan untuk domain Anda, serta apakah sertifikat Wildcard juga dikeluarkan untuk itu.

Tambahkan situs web Anda ke Daftar Preload HSTS

HTTP Strict Transport Security, atau HSTS, adalah header HTTP yang memaksa browser hanya untuk membuat koneksi HTTPS dengan situs tertentu. Dengan cara ini, bahkan jika pengguna web mencoba untuk pergi ke versi HTTP halaman, mereka hanya akan mengunjungi versi HTTPS. Itu penting karena menutup jendela pada beberapa eksploit yang diketahui, seperti serangan downgrade dan pembajakan cookie.

Sayangnya, vektor serangan kecil tetap dengan HSTS, itulah sebabnya Anda harus menambahkan situs web Anda ke daftar preload. Biasanya, ketika seorang pengunjung tiba di situs web Anda, peramban mereka akan mengunduh tajuk HTTP dan kemudian mematuhinya selama berapa lama kebijakan telah ditetapkan untuk bertahan lama. Tetapi pada kunjungan pertama itu, sebelum sundulan diterima, masih ada celah kecil untuk penyerang.

Daftar rekaman awal HSTS dijalankan oleh Google dan beberapa variasi daripadanya digunakan oleh semua browser utama. Browser itu hanya tahu untuk terhubung melalui HTTPS ke situs web apa pun yang ada dalam daftar — bahkan jika itu belum pernah dikunjungi di sana sebelumnya. Mungkin diperlukan satu atau dua minggu untuk situs Anda muncul di daftar karena fakta bahwa pembaruan daftar didorong keluar bersamaan dengan jadwal rilis browser.

FAQ SSL / TLS

Apa itu sertifikat X.509?

X.509 mengacu pada jenis sertifikat digital yang digunakan dengan SSL / TLS dan jenis PKI lainnya. X.509 adalah standar enkripsi kunci publik. Kadang-kadang Anda akan melihat perusahaan menggunakan sertifikat X.509 sebagai pengganti certificate sertifikat digital ’atau I sertifikat PKI.’

Mengapa sertifikat SSL / TLS kedaluwarsa?

Ada dua alasan untuk ini.

Yang pertama adalah bahwa internet terus berubah, situs web datang, dan situs web pergi. Dan mengingat betapa sensitifnya browser tentang mempercayai sertifikat ini di tempat pertama mereka ingin tahu bahwa situs web yang menyajikan sertifikat sedang menjalani validasi reguler. Ini tidak jauh berbeda dari bagaimana Anda sesekali harus check-in untuk memperbarui informasi pada SIM Anda.

Alasan lainnya lebih teknis. Lebih sulit untuk memperbanyak pembaruan dan perubahan teknis ketika sertifikat tidak kedaluwarsa dalam 3-5 tahun. Padahal, jika sertifikat kedaluwarsa setiap 24 bulan, sertifikat yang paling lama bisa kedaluwarsa adalah dua tahun. Pada 2017, validitas maksimum dikurangi dari tiga tahun menjadi dua. Kemungkinan akan dipersingkat menjadi 12 bulan segera.

Bagaimana Anda memperbarui sertifikat SSL / TLS?

Pembaruan bisa sedikit keliru karena Anda mengganti sertifikat lama dengan yang baru dikeluarkan. Melakukan hal ini secara teratur memungkinkan Anda untuk tetap mendapatkan informasi terkini dengan kemajuan baru dengan teknologi enkripsi dan memastikan informasi validasi Anda tetap terbarui. CA hanya dapat menggunakan kembali informasi validasi yang awalnya diberikan begitu lama sebelum persyaratan dasar memaksa mereka untuk memvalidasinya kembali.

Saat memperbarui, Anda dapat menyimpan jenis sertifikat yang sama dengan yang Anda miliki sebelumnya, atau Anda dapat menggunakan sesuatu yang baru, Anda bahkan dapat mengubah CA. Yang penting adalah berapa banyak waktu yang tersisa untuk sertifikat yang kedaluwarsa — Anda dapat melanjutkan hingga tiga bulan. Selama Anda memperbarui sebelum sertifikat berakhir, Anda dapat melanjutkan waktu yang tersisa dan menggunakan kembali informasi validasi apa pun yang belum kehabisan waktu sejak validasi terakhir Anda. Jika Anda membiarkannya berakhir, Anda mulai dari awal.

Apa itu Pemeriksaan HTTPS?

Banyak perusahaan besar dengan jaringan yang lebih besar ingin memiliki visibilitas atas lalu lintas mereka. Dalam hal itu, HTTPS adalah pedang bermata dua. Ini melindungi privasi orang, tetapi juga dapat membantu penjahat cyber bersembunyi juga. Banyak organisasi akan mendekripsi lalu lintas HTTPS mereka di perangkat tepi atau middlebox dan kemudian mengirimkannya bersama dalam plaintext di belakang firewall mereka atau mengenkripsi ulang dan mengirimkannya di jalan. Saat Anda tidak mengenkripsi ulang lalu lintas, itu disebut Pengakhiran SSL. Saat Anda mengenkripsi ulang, itu disebut SSL bridging.

Apa itu pembongkaran SSL?

Pembongkaran SSL adalah praktik perusahaan lainnya. Pada skala, melakukan ribuan jabat tangan dan kemudian mengenkripsi dan mendekripsi semua data yang dapat membebani sumber daya jaringan. Jadi, banyak jaringan yang lebih besar akan membongkar fungsi SSL ke perangkat lain sehingga server aplikasi dapat fokus pada tugas-tugas intinya. Ini kadang-kadang disebut sebagai load balancing.

Mengapa CA saya mengirim saya sertifikat perantara?

Ingat sebelumnya ketika kita membahas program root?

Very OS memiliki root store yang digunakannya untuk membuat penilaian kepercayaan PKI. Tetapi CA tidak mengeluarkan sertifikat pengguna akhir dari akar tersebut karena takut akan apa yang akan terjadi jika seseorang harus dicabut. Sebaliknya, mereka memutar akar perantara dan mengeluarkannya. Masalahnya adalah akar perantara tersebut tidak berada di toko trust sistem.

Jadi, jika situs web tidak menampilkan sertifikat perantara bersama dengan sertifikat SSL SSL / TLS, banyak browser tidak akan dapat menyelesaikan rantai sertifikat dan akan mengeluarkan peringatan. Beberapa browser melakukan sertifikat perantara tembolok, tetapi masih dianggap praktik terbaik untuk memasang perantara apa pun bersama dengan sertifikat daun Anda.

Dokumentasi apa yang saya perlukan untuk sertifikat SSL Validasi Diperpanjang?

Dalam kebanyakan kasus, Otoritas Sertifikat yang melakukan validasi yang diperluas akan terlebih dahulu mencoba mengakses informasi melalui sumber daya “otoritas pemerintah” yang tersedia untuk umum.

Namun, di beberapa lokasi, ini mungkin tidak dapat dilakukan. Ada beberapa hal yang dapat membantu mempercepat validasi. Sementara jumlah pemeriksaan validasi yang dapat dipenuhi oleh Surat Opini Profesional telah berkurang baru-baru ini, memiliki seorang pengacara atau akuntan yang memiliki reputasi baik masih dapat membantu secara signifikan..

Selain itu, Anda dapat memberikan kredensial bisnis yang dikeluarkan pemerintah atau dokumen “Bukti Hak” yang memberi organisasi Anda hak untuk melakukan bisnis dengan nama yang tercantum. Beberapa contoh dari dokumen-dokumen ini adalah:

  • Artikel Pendirian
  • Sertifikat Formasi
  • Lisensi Bisnis / Vendor / Pedagang
  • Dokumen piagam
  • Perjanjian kemitraan
  • Registrasi Nama Dagang atau Asumsi
  • Registro Mercantil

Dalam Penutupan

Saya harap ini memberi Anda ide tentang SSL / TLS. Jika Anda tertarik untuk belajar lebih banyak, maka saya akan merekomendasikan mengambil kursus online ini.

Posting ini disumbangkan oleh Patrick Nohe, editor Hashed Out oleh The SSL Store, sebuah blog yang meliput berita dan tren cybersecurity.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map