Protokol VPN

6.2 Protokol VPN

Ada beberapa cara untuk mencapai kebutuhan enkripsi VPN. Protokol jaringan tertentu sering digunakan untuk VPN. Dua protokol yang paling umum digunakan untuk tujuan ini adalah Protokol Tunneling Point-to-Point (PPTP) dan Protokol Tunneling Layer 2 (L2TP). Bagian dari koneksi di mana data dienkapsulasi disebut sebagai tunnel. L2TP sering dikombinasikan dengan IPSec untuk mencapai tingkat keamanan yang tinggi. 

6.2.1 PPTP

PPTP adalah protokol tunneling yang memungkinkan protokol koneksi yang lebih lama, PPP (Point-to-Point Protocol), untuk memiliki paket yang dikemas dalam paket Internet Protocol (IP) dan diteruskan melalui jaringan IP apa pun, termasuk Internet itu sendiri. PPTP sering digunakan untuk membuat VPN. PPTP adalah protokol yang lebih tua dari L2TP atau IPSec. Beberapa ahli menganggap PPTP kurang aman dibandingkan L2TP atau IPSec, tetapi menghabiskan lebih sedikit sumber daya dan didukung oleh hampir setiap implementasi VPN. Ini pada dasarnya adalah ekstensi aman untuk PPP.

PPTP awalnya diusulkan sebagai standar pada tahun 1996 oleh Forum PPTP — kelompok perusahaan yang meliputi Ascend Communications, ECI Telematics, Microsoft, 3Com, dan US Robotics. Tujuan grup ini adalah untuk merancang protokol yang memungkinkan pengguna jarak jauh untuk berkomunikasi dengan aman melalui Internet.

Meskipun protokol VPN yang lebih baru tersedia, PPTP masih banyak digunakan, karena hampir semua vendor peralatan VPN mendukung PPTP. Manfaat penting lainnya dari PPTP adalah bahwa ia beroperasi pada lapisan 2 model OSI (lapisan data link), yang memungkinkan protokol jaringan yang berbeda untuk berjalan di atas terowongan PPTP. 

Saat menghubungkan pengguna ke sistem jarak jauh, mengenkripsi transmisi data bukan satu-satunya aspek keamanan. Anda juga harus mengautentikasi pengguna. PPTP mendukung dua teknologi terpisah untuk mencapai hal ini: Extensible Authentication Protocol (EAP) dan Challenge Handshake Authentication Protocol (CHAP).

6.2.1.1 Protokol Otentikasi yang Diperluas (EAP)

EAP dirancang khusus dengan PPTP dan dimaksudkan untuk berfungsi sebagai bagian dari PPP. EAP bekerja dari dalam protokol otentikasi PPP. Ini memberikan kerangka kerja untuk beberapa metode otentikasi yang berbeda. EAP dimaksudkan untuk menggantikan sistem otentikasi berpemilik dan mencakup berbagai metode otentikasi yang akan digunakan, termasuk kata sandi, token respons-tantangan, dan sertifikat infrastruktur kunci publik.

6.2.1.2 Tantangan Protokol Otentikasi Jabat Tangan (CHAP)

CHAP sebenarnya adalah prosedur handshaking tiga bagian (istilah yang digunakan untuk menunjukkan proses otentikasi). Setelah tautan dibuat, server mengirimkan pesan tantangan ke mesin klien yang memulai tautan. Pencetus merespons dengan mengirimkan kembali nilai yang dihitung menggunakan fungsi hash satu arah. Server memeriksa respons terhadap perhitungannya sendiri dari nilai hash yang diharapkan. Jika nilainya cocok, otentikasi diakui; jika tidak, koneksi biasanya terputus. Ini berarti bahwa otorisasi koneksi klien memiliki tiga tahap.

 

Apa yang membuat CHAP sangat menarik adalah bahwa ia mengulangi proses secara berkala. Ini berarti bahwa bahkan setelah koneksi klien diautentikasi, CHAP berulang kali berupaya untuk mengautentikasi ulang klien itu, memberikan tingkat keamanan yang kuat.

6.2.2 L2TP

Layer 2 Tunneling Protocol adalah perpanjangan atau peningkatan dari Point-to-Point Tunneling Protocol yang sering digunakan untuk mengoperasikan jaringan pribadi virtual melalui Internet. Pada dasarnya, ini adalah versi PPTP yang baru dan lebih baik. Seperti namanya, ini beroperasi pada lapisan data link model OSI (seperti PPTP). Baik PPTP dan L2TP dianggap oleh banyak ahli kurang aman dibandingkan IPSec. Namun, melihat IPSec digunakan bersama dengan L2TP untuk membuat koneksi VPN yang aman bukanlah hal yang biasa.

Seperti PPTP, L2TP mendukung EAP dan CHAP. Namun, ia juga menawarkan dukungan untuk metode otentikasi lainnya, dengan total enam:

• EAP
• BAB
• MS-CHAP
• PAP
• SPAP
• Kerberos

6.2.2.1 MS-CHAP

Seperti namanya, MS-CHAP adalah ekstensi khusus Microsoft untuk CHAP. Microsoft membuat MS-CHAP untuk mengautentikasi workstation Windows jarak jauh. Tujuannya adalah untuk menyediakan fungsionalitas yang tersedia di LAN untuk pengguna jarak jauh sambil mengintegrasikan enkripsi dan algoritma hashing yang digunakan pada jaringan Windows.

Jika memungkinkan, MS-CHAP konsisten dengan CHAP standar. Namun, beberapa perbedaan mendasar antara MS-CHAP dan CHAP standar meliputi yang berikut:

• Paket tanggapan MS-CHAP dalam format yang dirancang untuk kompatibilitas dengan produk-produk jaringan Microsoft Windows.
• Format MS-CHAP tidak memerlukan autentikator untuk menyimpan teks yang jelas atau kata sandi yang dienkripsi terbalik.
• MS-CHAP menyediakan coba ulang otentikasi yang dikendalikan oleh autentikator dan mekanisme pengubahan kata sandi. Coba lagi dan mekanisme pengubahan kata sandi ini kompatibel dengan mekanisme yang digunakan dalam jaringan Windows.
• MS-CHAP mendefinisikan seperangkat kode alasan-untuk-kegagalan yang dikembalikan dalam bidang pesan paket kegagalan jika otentikasi gagal. Ini adalah kode yang dapat dibaca dan diinterpretasikan oleh perangkat lunak Windows, sehingga memberikan alasan kepada pengguna untuk otentikasi yang gagal.

6.2.2.2 PAP

Protokol Otentikasi Sandi (PAP) adalah bentuk otentikasi paling dasar. Dengan PAP, nama pengguna dan kata sandi ditransmisikan melalui jaringan dan dibandingkan dengan tabel pasangan nama-kata sandi. Biasanya, kata sandi yang disimpan dalam tabel dienkripsi. Namun, transmisi kata sandi dalam teks yang jelas, tidak terenkripsi, kelemahan utama dengan PAP. Fitur otentikasi dasar yang dibangun ke dalam protokol HTTP menggunakan PAP. Metode ini tidak lagi digunakan dan hanya disajikan untuk tujuan historis.

6.2.2.3 SPAP

Shiva Password Authentication Protocol (SPAP) adalah versi eksklusif dari PAP. Sebagian besar pakar menganggap SPAP agak lebih aman daripada PAP karena nama pengguna dan kata sandi keduanya dienkripsi saat dikirim, tidak seperti PAP. 

Karena SPAP mengenkripsi kata sandi, seseorang yang mengambil paket otentikasi tidak akan dapat membaca kata sandi SPAP. Namun, SPAP masih rentan terhadap serangan playback (yaitu, seseorang merekam pertukaran dan memutar pesan kembali untuk mendapatkan akses curang). Serangan pemutaran dimungkinkan karena SPAP selalu menggunakan metode enkripsi yang dapat dibalik yang sama untuk mengirim kata sandi melalui kabel.

6.2.2.4 Kerberos

Kerberos adalah salah satu protokol otentikasi jaringan yang paling terkenal. Itu dikembangkan di MIT dan itu dinamai dari anjing berkepala tiga mitos yang menjaga gerbang ke Hades.

Kerberos bekerja dengan mengirim pesan bolak-balik antara klien dan server. Kata sandi aktual (atau bahkan kata sandi) tidak pernah dikirim. Itu membuat mustahil bagi seseorang untuk mencegatnya. Yang terjadi adalah bahwa nama pengguna dikirim. Server kemudian mencari hash yang tersimpan dari kata sandi itu, dan menggunakannya sebagai kunci enkripsi untuk mengenkripsi data dan mengirimkannya kembali ke klien. Klien kemudian mengambil kata sandi yang dimasukkan pengguna, dan menggunakannya sebagai kunci untuk mendekripsi data. Jika pengguna memasukkan kata sandi yang salah, maka kata sandi itu tidak akan pernah didekripsi. Ini adalah cara cerdas untuk memverifikasi kata sandi tanpa pernah dikirimkan. Otentikasi terjadi dengan UDP (User Datagram Protocol) pada port 88.

Setelah nama pengguna pengguna dikirim ke layanan otentikasi (AS), AS itu akan menggunakan hash kata sandi pengguna yang disimpan sebagai kunci rahasia untuk mengenkripsi dua pesan berikut yang dikirimkan ke klien:

• Pesan A: Berisi kunci sesi Klien / TGS (Layanan Pemberian Tiket) yang dienkripsi dengan kunci rahasia klien
• Pesan B: Berisi TGT (Tiket Pemberian Tiket) yang mencakup ID klien, alamat jaringan klien, dan periode validitas

Ingat, kedua pesan ini dienkripsi menggunakan kunci yang dihasilkan AS.

Kemudian pengguna mencoba mendekripsi pesan A dengan kunci rahasia yang dihasilkan oleh klien untuk mem-hashing kata sandi yang dimasukkan pengguna. Jika kata sandi yang dimasukkan tidak cocok dengan kata sandi AS yang ditemukan dalam database, maka hash tidak akan cocok, dan dekripsi tidak akan berfungsi. Jika berhasil, maka pesan A berisi kunci sesi Klien / TGS yang dapat digunakan untuk komunikasi dengan TGS. Pesan B dienkripsi dengan kunci rahasia TGS dan tidak dapat didekripsi oleh klien.

Sekarang pengguna diautentikasi ke dalam sistem. Namun, ketika pengguna benar-benar meminta layanan, beberapa komunikasi pesan diperlukan. Saat meminta layanan, klien mengirim pesan berikut ke TGS:

• Pesan C: Terdiri dari TGT dari pesan B dan ID dari layanan yang diminta
• Pesan D: Authenticator (yang terdiri dari ID klien dan stempel waktu), dienkripsi menggunakan kunci sesi Klien / TGS

Setelah menerima pesan C dan D, TGS mengambil pesan B dari pesan C. Ini mendekripsi pesan B menggunakan kunci rahasia TGS. Ini memberinya "kunci sesi Klien / TGS". Menggunakan kunci ini, TGS mendekripsi pesan D (Authenticator) dan mengirimkan dua pesan berikut ke klien:

• Pesan E: Tiket klien ke server (yang mencakup ID klien, alamat jaringan klien, masa berlaku, dan kunci sesi klien / server) dienkripsi menggunakan kunci rahasia layanan
• Pesan F: Kunci sesi klien / server dienkripsi dengan kunci sesi Klien / TGS

Setelah menerima pesan E dan F dari TGS, klien memiliki informasi yang cukup untuk mengotentikasi dirinya ke Server Layanan (SS). Klien terhubung ke SS dan mengirim dua pesan berikut:

• Pesan E: Dari langkah sebelumnya (tiket klien ke server, dienkripsi menggunakan kunci rahasia layanan)
• Pesan G: Otentikator baru, yang mencakup ID klien dan stempel waktu dan dienkripsi menggunakan kunci sesi klien / server

SS mendekripsi tiket (pesan E) menggunakan kunci rahasia sendiri untuk mengambil kunci sesi klien / server. Menggunakan kunci sesi, SS mendekripsi Authenticator dan mengirim pesan berikut ke klien untuk mengkonfirmasi identitas dan kesediaannya untuk melayani klien:

• Pesan H: Stempel waktu ditemukan di Authenticator klien

Klien mendekripsi konfirmasi (pesan H) menggunakan kunci sesi klien / server dan memeriksa apakah cap waktu sudah benar. Jika demikian, maka klien dapat mempercayai server dan dapat mulai mengeluarkan permintaan layanan ke server. Server menyediakan layanan yang diminta kepada klien.

Berikut adalah beberapa istilah Kerberos yang perlu diketahui:

• Kepala Sekolah: Server atau klien tempat Kerberos dapat menetapkan tiket.
• Layanan Otentikasi (AS): Layanan yang mengotorisasi kepala sekolah dan menghubungkan mereka ke Server Pemberian Tiket. Perhatikan beberapa buku / sumber mengatakan server daripada layanan.
• Layanan Pemberian Tiket (TGS): Menyediakan tiket.
• Key Distribution Center (KDC): Server yang menyediakan tiket awal dan menangani permintaan TGS. Seringkali ia menjalankan layanan AS dan TGS.

Realm: Batas dalam organisasi. Setiap ranah memiliki AS dan TGS sendiri.

• Server Pemberian Tiket Jauh (RTGS): TGS di ranah jauh.
• Ticket Granting Ticket (TGT): Tiket yang diberikan selama proses otentikasi. 
• Tiket: Digunakan untuk mengautentikasi ke server. Berisi identitas klien, kunci sesi, cap waktu, dan checksum. Dienkripsi dengan kunci server.
• Kunci sesi: Kunci enkripsi sementara.
• Authenticator: Membuktikan kunci sesi baru-baru ini dibuat. Sering kedaluwarsa dalam 5 menit.

Share this post