🌁 👩🏽‍🚀 💅 Pengantar TLS untuk Patrik Patrick (Bagian 1) 👩🏽‍🤝‍👨🏻 🥔 👈🏽

Seperti yang mungkin sudah Anda ketahui, ini Patrick. Dia adalah bintang laut, yang berarti bahwa adalah mungkin, tanpa menghinanya, untuk mengatakan bahwa tangannya tumbuh dari satu tempat. Patrick juga sangat praktis dan segera melupakan semua yang tidak dia butuhkan - tetapi jika dia membutuhkan sesuatu, dia ingin mengetahuinya (karena dia membutuhkannya!). Spoiler: di sini Patrick mencoba melakukan Jabat Tangan TLS.

Artikel ini ditulis untuk Patrick dan orang-orang seperti dia. Dia lahir dari presentasi yang pertama kali ditampilkan di Plesk TechTalk, pendidikan internal kami, di mana karyawan dalam bentuk yang dapat diakses saling berbagi informasi tentang teknologi, proses, dan solusi yang menarik. Oleh karena itu, gambar dalam artikel ini akan terlihat seperti slide :) Penulis teks asli laporan ini adalah manajer program Plesk Ruslan Kosolapov .

Biasanya, semua materi TLS mencakup beberapa aspek kecil, tetapi bukan gambaran besarnya. Ini tidak terlalu praktis dan Patrick pusing karenanya. Semuanya akan berbeda di sini: secara singkat, berlaku "dalam kehidupan sehari-hari" dan selengkap mungkin.

Apa itu TLS dan mengapa itu untuk Patrick

TLS (Transport Layer Security) adalah protokol perlindungan layer transport. Ini diperlukan agar tidak ada yang bisa "mendengarkan" Anda dan mencari tahu beberapa informasi penting (paling sering kata sandi, jika kita berbicara tentang bekerja di jaringan). Dan juga untuk melindungi diri dari pemalsuan dan modifikasi lalu lintas selama transmisi. Dalam dua hal inilah tujuan kebohongan TLS.

Untuk kejelasan, mari kita pertimbangkan jabat tangan TLS sebagai panggilan ke Patrick SpongeBob. Selama panggilan, seseorang dapat menguping pembicaraan (berdiri di sebelah Patrick atau menghidupkan di tengah-tengah garis), dan umumnya SpongeBob mungkin tidak berada di ujung lain - semua masalah ini relevan. Dan untuk menyelesaikannya, Patrick ingin menggunakan TLS.

Singkatnya, jabat tangan tingkat atas terlihat seperti ini:

Patrick: Saya ingin menggunakan TLS, versi cipher adalah ini dan itu.
Spongebob: Ok, mari kita gunakan versi cipher ini dan itu.

Setelah itu, SpongeBob mengirimkan sertifikat, Patrick memeriksanya, mengatakan bahwa semuanya baik-baik saja, kunci sesi sudah selesai (sebenarnya ada dua, tetapi tidak masalah). Mengapa menggunakan kunci sesi daripada enkripsi asimetris - karena lebih cepat. Setelah itu, mereka mulai berbicara bahasa yang tidak dapat dipahami dengan dekripsi. Dengan demikian, semuanya terlindungi.

Segalanya tampak sederhana. Cara kerjanya pada perangkat keras tidak begitu penting bagi kami. Tetapi jika Anda mulai berpikir - dan Patrick mulai berpikir! - yang menimbulkan pertanyaan tentang bagaimana menyetujui secara umum bahwa kami akan menggunakan TLS? Lagi pula, sekali tidak ada TLS, tetapi hanya ada protokol biasa - SMTP, HTTP. Bagaimana cara mengatakan apa yang dibutuhkan di TLS? Dan di sini di industri kami semuanya seperti biasa - ada banyak cara!

Awalnya mereka ingin menggunakan port tertentu, yang akan menyiratkan penggunaan TLS di atasnya. Apa kerugiannya? Dan mengapa kemudian metode eksplisit (eksplisit) untuk memulai sesi TLS muncul? Ada beberapa alasan:

Anda membutuhkan banyak port - dan port adalah hal yang tidak ingin Anda belanjakan. Karena semakin banyak ada, semakin sulit untuk mengkonfigurasi firewall.
Server dapat mengabaikan ini - ia telah terhubung ke port 443, dan tidak ada TLS di sana, hanya HTTP tanpa HTTPS.
Sebelum koneksi dibuat, Anda tidak dapat mengetahui apakah server TLS didukung atau tidak.

Semua ini mengarah pada munculnya metode eksplisit - ketika kita terhubung ke port reguler, dan kemudian memutakhirkan sesi kita ke TLS. Untuk layanan yang berbeda, protokol memiliki perintah yang berbeda, misalnya, untuk SMTP ada perintah terpisah di tingkat protokol SMTP - STARTTLS . HTTP juga memiliki lelucon seperti itu, disebut Upgrade: TLS / 1.0 . Pada tingkat protokol, lebih mudah untuk memahami apakah server TLS didukung atau tidak.

Mari kita membahas lebih jauh tentang berbagai jenis koneksi dan bagaimana hal-hal dengan TLS untuk mereka.

Hubungkan: HTTP

Segalanya akan mudah jika, seperti biasa, tidak ada nuansa. Dalam hal HTTP, persyaratan keamanan yang berkembang memberikan evolusi konstan dari proses bekerja dengan TLS. Pada awalnya ada pengalihan ke HTTPS, dan ini dilakukan hanya di header. Ini meninggalkan celah untuk kerentanan, jadi sesama Google datang dengan HSTS (HTTP Strict Transport Security). Ini adalah tajuk dalam respons HTTP yang memberi tahu browser: "harap diingat bahwa ketika Anda datang ke domain ini, langsung ke HTTPS, bahkan jika orang tersebut menyuruh Anda untuk pergi ke HTTP". Dengan demikian, tidak ada redirect dan semuanya terjadi jauh lebih aman. Selain itu, Google memiliki inisiatif lain - Anda dapat meninggalkan permintaan sehingga situs Anda ditambahkan ke daftar untuk Google Chrome “Selalu gunakan HTTPS”, terlepas dari judul apa pun.

Secara singkat: HSTS memecahkan pengalihan dari kerentanan HTTP ke HTTPS, sehingga hampir semua browser mendukung HSTS, yang bagus.

Connect: exotic (versi HTTP baru dan tidak hanya)

Dalam HTTP / 2, semuanya baik-baik saja dengan TLS: selalu digunakan (seperti browser yang dibuat sekarang). Selain itu, TLS dalam HTTP / 2 harus segar - yaitu, memiliki versi 1.2+.

Kemungkinan besar, segera Google akan menjual penggunaan HTTP / 3 yang meluas, sekarang sudah diadopsi oleh standar IANA. Kisah penampilan dan perkembangannya agak membingungkan; Hal utama yang perlu diingat Patrick:

HTTP / 3 selalu TLS 1.3+.
HTTP / 3 didasarkan pada QUIC - itu adalah protokol seperti di atas UDP, yang, menurut Google, lebih baik daripada TCP. Sebenarnya, sebelum nama HTTP / 3 akhirnya disetujui, protokol itu disebut HTTP-over-QUIC.

Masih ada protokol SCTP yang menarik, yang digunakan terutama di bidang telekomunikasi. Di atasnya, baik TLS dan DTLS digunakan (ini adalah TLS untuk UDP).

Secara singkat: dalam 2 tahun, QUIC (mis. HTTP / 3) akan digunakan di mana-mana, tetapi sekarang seharusnya sudah ada HTTP / 2 di mana-mana, tetapi pada kenyataannya tidak ada di mana-mana.

Hubungkan: Email

Banyak klien percaya bahwa harus ada TLS pada port 587, tetapi ada juga nuansa di sini: seseorang mengharapkan TLS secara default, dan seseorang mengharapkan permintaan STARTTLS eksplisit dari klien. Karena itu, berbagai kombinasi server surat dan klien surat terkadang menyebabkan efek yang tidak diinginkan. Sebagai contoh, klien memasuki port 587, mengharapkan bahwa akan ada TLS, sementara server menunggu klien untuk secara eksplisit meminta STARTTLS . Setelah tidak menerima apa-apa, klien kembali ke port 25. Hasilnya adalah beralih diam ke koneksi SMTP tidak aman. Saat menguji dan mengembangkan, perlu diingat tentang efek kombinasi server-klien. Autodiscaver memiliki berbagai opsi untuk menentukan TLS: bagaimana seharusnya, apa yang diharapkan, dan apa yang harus dilakukan. Banyak klien email memahami hal-hal ini.

Secara singkat: dengan dukungan TLS di server surat dan klien surat semuanya baik-baik saja secara umum, tetapi dalam kasus khusus mungkin ada masalah dan ekstensi TLS tidak didukung dengan sangat baik.

Hubungkan: FTP

Sedikit yang bisa dikatakan di sini. Masalah utama adalah SNI (ini saat domain yang berbeda memiliki IP yang sama). Di tingkat FTP, nama domain tidak ditransfer. Dalam versi eksplisit, itu tidak bisa berfungsi, karena tidak ada tempat untuk menulisnya. Ada beberapa opsi solusi - beberapa tawaran jadi, yang lain jadi, solusi umum belum diadopsi, tidak ada standar.

Secara singkat: ada beberapa jenis dukungan TLS untuk FTP (FTPS, SFTP - analog FTP yang diimplementasikan melalui SSH), tetapi beberapa aspek tidak tercakup karena keterbatasan teknis dari FTP itu sendiri.

Jabat Tangan TLS

Jadi, sekarang kita tahu bagaimana memulai komunikasi menggunakan TLS dalam koneksi yang berbeda, dan Patrick dapat mengomunikasikan keinginannya kepada SpongeBob. Setelah mereka sepakat bahwa mereka akan menggunakan TLS, Handshake TLS diproduksi. Hasilnya harus berupa kesepakatan antara klien dan server tentang cara mereka mengenkripsi semuanya. Selain itu, klien harus memastikan bahwa server adalah yang diperlukan. Terkadang server juga memeriksa klien (tetapi lebih jarang).

Cipher dan Versi

Seperti yang telah disebutkan, langkah pertama adalah memilih versi TLS dan cipher mana yang akan digunakan untuk enkripsi. Biasanya, cipher terlihat seperti ini:

Suite cipher ada di registri IANA, dan dalam protokol TLS dalam bentuk biner hanya ID-nya. Seperti yang Anda lihat pada gambar, di sini bukan hanya (dan tidak hanya) cipher, tetapi juga mode operasinya dan detail lainnya yang diperlukan untuk jabat tangan TLS. Patrick tidak perlu merinci. Yang penting pada tahap ini adalah untuk mengingat bahwa surat-surat ini baik (dan sisanya buruk):

DHE
ECDhe
AES128
AES256
RSA
Ecdsa
Cbc
Gcm
SHA256
SHA383
CHACHA20
POLY1308

Gambar untuk mengingat sandi yang baik:

Jika sulit diingat, ada layanan yang baik yang dapat memberi tahu Anda tentang hal itu, misalnya, layanan dari Mozilla ssl-config.mozilla.org .

Anda dapat segera melihat di mana dan bagaimana itu didukung - ini adalah apa yang sedang berusaha diikuti oleh para Mozilla.

Detail yang menarik: klien mentransfer cipher dalam urutan prioritas sesuai dengan preferensi mereka, tetapi server dibiarkan dengan keputusan - memilih cipher yang tampaknya menjadi yang terbaik dari daftar klien yang didukung.

Kedua belah pihak juga menunjukkan versi maksimum protokol yang didukung - dalam hal ini, Patrick lebih maju daripada SpongeBob.

Sebenarnya sertifikat

Bersama dengan jawaban "Ayo lakukan seperti ini", server mengirimkan sertifikat atau sertifikatnya - mungkin ada banyak.

Apa itu sertifikat? Ini adalah hubungan informasi (subjek) - paling sering itu adalah nama domain atau organisasi - dan kunci publik (kunci publik). Yaitu, sertifikat mengatakan: “Bung, kunci publik saya seperti itu. Sekarang, dengan bantuannya, kami akan menyetujui kunci sesi. ” Juga, dengan bantuannya, Anda dapat memeriksa tanda tangan sertifikat atau yang lainnya. Artinya, pada prinsipnya, dimungkinkan untuk menggunakan bukan sertifikat, tetapi mendaftar di mana hubungan ini ditunjukkan. Dan pada kenyataannya, langkah-langkah ke arah ini terus berlanjut, karena mekanisme Otoritas Sertifikat dianggap tidak terlalu baik, tidak ada yang lain.

Dengan demikian, sertifikat tersebut adalah struktur 'Subjek: Kunci publik' ditambah tanda tangan ishyuer (penerbit dalam transliterasi ke dalam bahasa Rusia terlihat mengerikan, tetapi sinonim terdekat di sini tidak terlalu dekat dalam konteks dengan “penerbit”) yang dikeluarkan oleh sertifikat ini. Ishüyer juga memiliki sertifikat dan koneksi seseorang dengan sesuatu. Anda dapat memeriksa sertifikat untuk kebenaran dengan mengambil kunci publik dari ishyuere dan memeriksa tanda tangan. Akibatnya, tidak ada yang bisa dipalsukan di sini.

Mari kita periksa sertifikat dan melihat masalah apa yang mungkin terjadi.

Pertama, Nomor seri menyiratkan keunikan hanya dalam batas ishyuere, meskipun beberapa perangkat lunak menganggapnya unik di seluruh alam semesta. Untungnya, lebih sering daripada tidak, itu benar-benar unik.

Sertifikat juga menunjukkan algoritma mana yang digunakan untuk enkripsi dan penandatanganan: RSA atau ECDSA - yaitu, kriptografi mana yang digunakan untuk bekerja dengan kunci publik ini. Perbedaan utama antara RSA dan ECDSA adalah bahwa prinsip matematika ECDSA didasarkan pada kurva eliptik, dan RSA adalah bilangan alami, sehingga lebih lambat dan kunci besar (3-4 ribu) digunakan untuk mencegahnya dari retak. . Dan untuk ECDSA, kunci 300-bit sudah cukup dan bekerja lebih cepat. Karena itu, banyak yang beralih ke ECDSA - jabat tangan itu sendiri berat dan saya ingin menguranginya. ECDSA dapat diminta ketika menerbitkan sertifikat, dan jika prospektor mendukungnya, ia akan melakukannya untuk Anda. Tetapi tanda tangan sertifikat tergantung pada kunci privat ishuiur saat ini, dan bukan pada apakah Anda meminta ECDSA atau RSA.Oleh karena itu, peramban dapat menunjukkan bahwa satu di tanda tangan dan lainnya di kunci publik, dan tidak perlu takut jika tanda tangannya bukan ECDSA.

Bagaimana cara mendapatkan sertifikat?

Singkatnya - seperti ini:

Patrick memberi tahu Otoritas Sertifikat: Saya perlu sertifikat. Orang ini (atau organisasi) memeriksa untuk melihat apakah itu Patrick. Cek bisa sangat berbeda. Tentu saja, Patrick sebagai klien mungkin tidak memiliki sertifikat, tetapi jika server tidak memiliki sertifikat, maka tidak akan ada TLS. Diperiksa apakah semuanya ditunjukkan dengan benar dalam aplikasi sertifikat, apakah Patrick benar-benar memiliki subjek yang dimintanya meminta sertifikat. Ini dilakukan oleh pusat Otoritas Sertifikat yang lebih tinggi - orang bersyarat yang diyakini semua orang. Untuk menerbitkan sertifikat, Anda perlu menyusun CSR (permintaan penandatanganan sertifikat, permintaan untuk sertifikat).

Ini juga merupakan struktur, yang cukup sulit untuk dikerjakan, karena ada beberapa layanan yang memungkinkan Anda untuk mengatur, menentukan, memverifikasi, dan melihat semuanya.

Total, kami menghasilkan sepasang kunci publik: kunci privat, tetapi kami hanya memberikan publik, dan menyembunyikan privat. Kemudian kami membuat Permintaan Penandatanganan Sertifikat dan menandatanganinya dengan kunci pribadi kami. Kami mengirim semua ini ke otoritas sertifikasi, dan ini memulai verifikasi. Ini bisa berbeda, terutama untuk sertifikat keren ada prosedur rumit khusus, tetapi kita akan membahas kasus umum.

CAA RR

Ada masalah sedemikian rupa sehingga orang-orang yang setiap orang percaya terkadang tidak terlalu baik. Salah satu alasan Symantec menjadi bagian dari DigiCert adalah karena Symantec mengeluarkan sertifikat tanpa meminta pemilik domain. Anda tidak dapat melakukan ini, itu menghina semua orang, tetapi yang paling penting bagi Symantec sendiri, karena Anda harus menjual bisnis Anda. Untuk membuat server tidak terlalu bergantung pada kawan-kawan yang tidak bermoral seperti itu, ada yang namanya CAA RR - sebuah catatan dalam DNS, di mana dikatakan siapa pemiliknya yang mengizinkan mengeluarkan sertifikat untuk domainnya. Fitur ini juga ada di Plesk, hanya digunakan sejauh ini, kira-kira seperti DNSSec, namun demikian. Semua otoritas sertifikasi setuju untuk memeriksa entri ini dan jika dikatakan bahwa otoritas sertifikasi ini tidak dapat dikeluarkan, ia akan mengatakan: "Anda tidak lulus validasi, itu ditulis dalam CAA RR,bahwa saya tidak dapat menulis sertifikat untuk Anda ”- dan tidak akan menuliskannya. Jika tidak ada entri, maka Anda bisa. Sekarang Google mendorong inisiatif sehingga pelanggan memeriksa sertifikat yang mereka terima untuk kesesuaian dengan catatan CAA RR. Perdebatan masih berlangsung.

Selain itu, CAA RR sejak kami memberikan dukungan di Plesk diperluas dengan menunjukkan metode validasi (yaitu, Anda juga dapat menunjukkan di sini dengan metode mana Anda memvalidasi bahwa domain ini milik Anda) dan URI Akun (Uniform Resource Identifier). Populer di kalangan pengguna Plesk Let's Encrypt sudah mendukung semua ini (dilakukan dengan baik!).

Semua ini berfungsi untuk semua jenis sertifikat, dan karena kita akan membicarakan perbedaannya nanti, sekarang saatnya untuk membicarakan jenis-jenisnya secara lebih rinci.

Jenis Sertifikat

Ada tiga di antaranya:

Validasi domain

Subjek adalah domain, yaitu, di sini kami hanya memeriksanya. Sebelumnya, ketika tidak ada validator otomatis, validasi dilakukan terutama melalui email melalui layanan Whois. Ini dianggap alasan yang cukup untuk percaya bahwa Anda adalah pemilik domain ini. Kemudian mereka berpikir memeriksa melalui DNS - mereka menulis kepada Anda melalui email: "dan menambahkan catatan ini dan itu ke DNS". Kemudian metode otomatis muncul (kita akan berbicara tentang ACME sedikit lebih jauh).

Validasi organisasi

Di bidang "subjek", selain nama domain, nama organisasi juga ditunjukkan. Cek terdiri dari memvalidasi apakah domain milik organisasi ini dan apakah orang yang datang untuk sertifikat bekerja di sana. Bagaimana ini dilakukan: mereka mencari organisasi di register, menelepon, meminta sesuatu untuk dilakukan (telepon ternyata benar, orang yang tepat menjawab, yang berarti kemungkinan besar semuanya baik-baik saja).

Validasi diperpanjang

Sama seperti OV, hanya lebih dingin. Semuanya sangat diatur di sini - dokumen 40 halaman dalam semangat "dalam paragraf 5.6.8 harus sebagai berikut: ...", dll. Banyak hal diperiksa - negara, departemen (jika ditunjukkan dalam aplikasi), dan kadang-kadang orang istimewa bahkan pergi untuk melihat dengan matanya. Apa perbedaan praktisnya? Hampir semua browser tidak lagi membedakan antara OV dan DV, dan ini buruk, karena dalam hal ini nama organisasi tidak ditampilkan. Akibatnya, tidak ada yang mau membuat domain aliepxress.ru, menggambar halaman yang sama dan mencuri kartu kredit. Dan itu benar-benar sah untuk membuat domain semacam itu dan mendapatkan sertifikat DV di atasnya.

Contoh dengan EV - nama organisasi terlihat di sini, jadi jika seseorang mencuri sesuatu, pengguna akan tahu bahwa itu adalah perusahaan Valve Corp, dan mendaftarkan perusahaan itu agak lebih sulit daripada domainnya (lebih banyak cek).

Namun, semuanya berjalan ke titik di mana EV akan berhenti berbeda, pada perangkat seluler tidak lagi terlihat dan Anda perlu menekan tombol terpisah, dan juga di Safari. Google Chrome masih memegang (UPD - tidak lagi! Saya harus membuat layar dari IE). Argumen dari mereka yang tidak menunjukkan: "jika Anda khawatir, klik dan lihat," tetapi tidak ada yang secara alami menekan.

Memperoleh Sertifikat: Otomasi

Sekarang mari kita bicara tentang penerimaan otomatis sertifikat DV. Untuk kejelasan, mari kita lihat bagaimana Enkripsi Mari favorit kita melakukannya. Dia umumnya memiliki dokumentasi yang baik, jika ada yang tertarik, dan bahkan dalam bahasa Rusia.

PUNCAK

ACME (Lingkungan Manajemen Sertifikat Otomatis) adalah protokol yang dirancang untuk mengotomatisasi dan membakukan proses memperoleh sertifikat.

Bagaimana ACME membuktikan Anda adalah pemilik domain? Anda berkata: Saya ingin sertifikat dan menunjukkan jenis validasi otomatis - misalnya, ACME HTTP-01. Let's Encrypt meminta Anda untuk memasukkan data ke file, dan jika Anda bisa meletakkan file di domain Anda (dan Let's Encrypt dapat mengambilnya dari sana melalui HTTP), Anda mungkin adalah pemiliknya. Sekarang pendekatan ini dikritik, termasuk dari Google, karena tidak melindungi terhadap phishing. Yaitu, dengan validasi manual, domain aliepxress.ru kemungkinan akan menimbulkan kecurigaan, tetapi Let's Encrypt sendiri sejauh ini tidak tahu bagaimana (atau bisa, tetapi buruk).

Tantangan DNS

Selain ACME, ada juga tantangan DNS. Misalnya, mereka memberi tahu Anda: masukkan catatan txt di zona DNS Anda, masukkan data di dalamnya. Ada cara lain, tetapi tidak umum, dan satu dibatalkan sama sekali, karena ternyata rentan. Apa yang kami miliki di Plesk: sertifikat wildcard (yang hanya dapat ditulis menggunakan tantangan DNS) tidak berfungsi untuk banyak orang, karena sangat sering Plesk tidak mengelola zona dan ekstensi domain DNS. Mari Enkripsi tidak dapat mengotomatiskan pembuatan catatan di zona DNS .

Dua kata lagi tentang Let's Encrypt

Aspek penting dalam bekerja dengan sertifikat Enkripsi Mari adalah batas. Jika ragu (atau dicurigai telah tercapai), yang terbaik adalah mengikuti tautan: letsencrypt.org/docs/rate-limits

Terkadang mereka diperbarui. Ada batasan yang tidak jelas yang dilupakan orang: paling sering, dilihat dari permintaan dukungan, mereka dihadapkan pada batas 100 nama domain dalam sertifikat. Let's Encrypt juga memiliki server pementasan dan ada lebih banyak batasan, tetapi sertifikat semacam itu dianggap tidak tepercaya dan untuk peramban mereka mirip dengan yang ditandatangani sendiri. Dalam praktiknya, dengan batas 100 nama, mereka jarang datang kepada kami (terlepas dari kenyataan bahwa situs di Plesk memiliki total 1.300.000 sertifikat Mari Enkripsi). Median, menurut statistik kami, adalah 20 nama per sertifikat. Jadi, jika sesuatu tidak berhasil, lihat - mungkin batasnya tercapai. Let's Encrypt memiliki pelaporan kesalahan yang baik, dan Anda biasanya dapat memahami apa yang terjadi.

Apa berikutnya?

Jadi, setelah sertifikat diterima, server mengirimkan data kunci sesi - inilah yang akan digunakan untuk enkripsi. Jika server menganggap perlu untuk mengautentikasi klien (misalnya, akses hanya terbuka untuk lingkaran orang tertentu), ia mungkin bertanya: klien, siapa Anda? Dan kemudian klien harus mengirim sertifikatnya. Setelah menerima pesan ServerHelloDone, klien menyadari bahwa sudah waktunya untuk memverifikasi sertifikat dan bekerja dengan kunci.

Segala sesuatu yang kita bicarakan, sebelum TLS 1.3 melewati saluran terbuka, dan siapa pun dapat melihat semua hal ini. Ada beberapa serangan menarik yang bisa Anda baca tentang diri Anda.
Dalam ~~seri~~ artikel kedua, kita akan belajar bagaimana klien memverifikasi sertifikat.

Pengantar TLS untuk Patrik Patrick (Bagian 1)