Apakah URL HTTPS dienkripsi?

1020

Apakah semua URL dienkripsi saat menggunakan enkripsi TLS / SSL (HTTPS)? Saya ingin tahu karena saya ingin semua data URL disembunyikan ketika menggunakan TLS / SSL (HTTPS).

Jika TLS / SSL memberi Anda enkripsi URL total, maka saya tidak perlu khawatir menyembunyikan informasi rahasia dari URL.

ssl  https  httprequest 
— Daniel Kivatinos
sumber
76
Mungkin itu ide yang buruk untuk memasukkan data rahasia ke dalam URL. Ini akan ditampilkan dalam alamat browser yang buruk juga, ingat? Orang tidak suka jika kata sandi mereka terlihat oleh siapa pun yang kebetulan melirik layar. Menurut Anda mengapa Anda perlu memasukkan data rahasia ke dalam URL?
— jalf
43
URL juga disimpan dalam riwayat browser dan log server - jika saya ingin nama dan kata sandi saya disimpan di suatu tempat, itu tidak akan berada di dua tempat ini.
— Piskvor meninggalkan gedung
47
Misalnya, saya mengunjungi https://somewhere_i_trust/ways_to_protest_against_the_government/. Kemudian URL tersebut berisi data rahasia, yaitu saran yang saya pertimbangkan untuk memprotes pemerintah saya.
— Steve Jessop
42
Saya bertanya pada diri sendiri pertanyaan ini ketika membuat permintaan HTTP dari Aplikasi asli (bukan berbasis browser). Saya menduga ini mungkin menarik bagi pengembang aplikasi seluler. Dalam hal ini, komentar di atas (sementara benar) tidak relevan (tidak ada url yang terlihat, tidak ada riwayat perambanan), membuat jawaban, menurut pemahaman saya sederhana: "Ya, terenkripsi".
— DannyA
23
Bagi mereka yang berpikir bahwa Anda adalah HTTPS, tidak ada yang tahu ke mana Anda akan pergi, bacalah ini terlebih dahulu: Nama host server (misalnya example.com) masih akan bocor karena SNI . Ini sama sekali tidak ada hubungannya dengan DNS dan kebocoran akan terjadi bahkan jika Anda tidak menggunakan DNS atau menggunakan DNS terenkripsi.
— Pacerier

Jawaban:

913

Ya, koneksi SSL berada di antara lapisan TCP dan lapisan HTTP. Klien dan server pertama-tama membuat koneksi TCP terenkripsi aman (melalui protokol SSL / TLS) dan kemudian klien akan mengirim permintaan HTTP (GET, POST, DELETE ...) melalui koneksi TCP terenkripsi.

— Marc Novakowski
sumber
98
Perlu dicatat hal yang disebutkan oleh @Jalf dalam komentar pada pertanyaan itu sendiri. Data URL juga akan disimpan dalam riwayat browser, yang mungkin tidak aman untuk jangka panjang.
— Michael Ekstrand
20
Bukan hanya GET atau POST. Bisa juga HAPUS, PUT, KEPALA, atau TRACE.
4
Ya itu bisa menjadi masalah keamanan untuk riwayat browser. Tetapi dalam kasus saya, saya tidak menggunakan browser (juga posting asli tidak menyebutkan browser). Menggunakan panggilan https khusus di belakang layar di aplikasi asli. Ini adalah solusi sederhana untuk memastikan koneksi terputus aplikasi Anda aman.
— zingle-dingle
28
Namun perhatikan bahwa tekad DNS dari URL mungkin tidak dienkripsi. Jadi seseorang mengendus traffic Anda mungkin masih dapat melihat domain yang Anda coba akses.
— ChewToy
21
SNI merusak bagian 'host' dari enkripsi URL SSL. Anda dapat menguji ini sendiri dengan wireshark. Ada pemilih untuk SNI, atau Anda bisa meninjau paket SSL Anda ketika Anda terhubung ke host jarak jauh.
— cmouse
654

Karena tidak ada yang memberikan tangkapan kawat, ini dia.
Nama Server (bagian domain dari URL) disajikan dalam ClientHellopaket, dalam teks biasa .

Berikut ini menunjukkan permintaan browser untuk:
https://i.stack.imgur.com/path/?some=parameters&go=here

ClientHello SNI Lihat jawaban ini untuk lebih lanjut tentang bidang versi TLS (ada 3 di antaranya - bukan versi, bidang yang masing-masing berisi nomor versi!)

Dari https://www.ietf.org/rfc/rfc3546.txt :

3.1. Indikasi Nama Server

[TLS] tidak menyediakan mekanisme bagi klien untuk memberi tahu server nama server yang dihubungi. Mungkin diinginkan bagi klien untuk memberikan informasi ini untuk memfasilitasi koneksi yang aman ke server yang menampung beberapa server 'virtual' pada satu alamat jaringan yang mendasarinya.

Untuk memberikan nama server, klien MUNGKIN menyertakan ekstensi tipe "nama_server" dalam halo (diperluas) klien.


Pendeknya:

  • FQDN (bagian domain dari URL) DAPAT dikirimkan secara jelas di dalam ClientHellopaket jika ekstensi SNI digunakan

  • Sisa URL ( /path/?some=parameters&go=here) tidak memiliki bisnis di dalam ClientHellokarena URL permintaan adalah hal HTTP (OSI Layer 7), oleh karena itu tidak akan pernah muncul dalam jabat tangan TLS (Layer 4 atau 5). Yang akan datang nanti dalam GET /path/?some=parameters&go=here HTTP/1.1permintaan HTTP, SETELAH yang aman saluran TLS didirikan.


RINGKASAN BISNIS PLAN

Nama domain DAPAT ditransmisikan dengan jelas (jika ekstensi SNI digunakan dalam jabat tangan TLS) tetapi URL (jalur dan parameter) selalu dienkripsi.


PEMBARUAN MARET 2019

Terima kasih carlin.scott untuk membawa yang ini.

Payload dalam ekstensi SNI sekarang dapat dienkripsi melalui draft proposal RFC ini . Kemampuan ini hanya ada di TLS 1.3 (sebagai opsi dan terserah kedua ujungnya untuk mengimplementasikannya) dan tidak ada kompatibilitas mundur dengan TLS 1.2 dan di bawah.

CloudFlare melakukannya dan Anda dapat membaca lebih lanjut tentang bagian dalam di sini - Jika ayam harus ada sebelum telur, di mana Anda meletakkan ayam?

Dalam praktiknya ini berarti bahwa alih-alih mentransmisikan FQDN dalam teks biasa (seperti yang ditunjukkan oleh penangkapan Wireshark), ia sekarang dienkripsi.

CATATAN: Ini membahas aspek privasi lebih daripada keamanan karena pencarian DNS balik MUNGKIN mengungkapkan host tujuan yang dituju.

— evilSnobu
sumber
37
Jawaban sempurna, dengan penjelasan lengkap dari A hingga Z. Saya suka ringkasan Eksekutif. Jadikan hariku @evilSnobu
— oscaroscar
4
Jawaban sempurna, upvote! Masih mempertimbangkan bagian klien karena riwayat browser mungkin bocor. Namun, mengenai lapisan transport, parameter URL dienkripsi.
— Jens Kreidler
2
Anda mungkin ingin memperbarui jawaban ini dengan fakta bahwa TLS 1.3 mengenkripsi ekstensi SNI, dan CDN terbesar melakukan hal itu: blog.cloudflare.com/encrypted-sni Tentu saja packet sniffer hanya dapat melakukan pencarian reverse-dns untuk alamat IP yang Anda hubungkan.
— carlin.scott
@evilSnobu, tetapi nama pengguna: kata sandi bagian dari nama pengguna: password@domain.com dienkripsi, bukan? Jadi aman untuk meneruskan data sensitif dalam url menggunakan https.
— Maksim Shamihulau
1
Mereka dienkripsi pada kabel (dalam transportasi) tetapi jika salah satu ujung (pengguna atau server) log URL ke file teks biasa dan tidak membersihkan kredensial ... sekarang itu percakapan yang berbeda.
— evilSnobu
159

Seperti yang telah ditunjukkan oleh jawaban lain , https "URL" memang dienkripsi. Namun, permintaan / respons DNS Anda saat menyelesaikan nama domain mungkin tidak, dan tentu saja, jika Anda menggunakan browser, URL Anda mungkin direkam juga.

— Zach Scrivena
sumber
21
Dan pencatatan URL penting karena ada peretasan Javascript yang memungkinkan situs yang sama sekali tidak terkait untuk menguji apakah URL yang diberikan ada dalam riwayat Anda atau tidak. Anda dapat membuat URL tidak dapat diakses dengan memasukkan string acak gondrong di dalamnya, tetapi jika itu URL publik maka penyerang dapat mengatakan bahwa itu telah dikunjungi, dan jika memiliki rahasia pendek di dalamnya, maka penyerang dapat dengan kasar memaksa bahwa dengan kecepatan yang masuk akal.
— Steve Jessop
8
@SteveJessop, berikan tautan ke "
— Pacerier
6
@Pacerier: tanggal retas tentu saja, tetapi yang saya bicarakan saat itu adalah hal-hal seperti stackoverflow.com/questions/2394890/… . Itu adalah masalah besar pada tahun 2010 bahwa masalah ini sedang diselidiki dan serangan disempurnakan, tapi saya tidak benar-benar mengikutinya saat ini.
— Steve Jessop
2
@Pacerier: lebih banyak contoh: webdevwonders.com/... , webdevwonders.com/...
— Steve Jessop
1
Anda dapat menggunakan OpenDNS dengan layanan DNS terenkripsi itu. Saya menggunakannya di Mac saya, tetapi saya menemukan versi Windows tidak berfungsi dengan baik. Tapi itu beberapa waktu yang lalu, jadi mungkin bisa berfungsi sekarang. Untuk Linux belum ada. opendns.com/about/innovations/dnscrypt
— SPRBRN
101

Seluruh permintaan dan respons dienkripsi, termasuk URL.

Perhatikan bahwa ketika Anda menggunakan HTTP Proxy, ia tahu alamat (domain) dari server target, tetapi tidak tahu jalur yang diminta pada server ini (yaitu permintaan dan respons selalu dienkripsi).

— Peter Štibraný
sumber
1
Keseluruhan permintaan. Nama Host dikirim dengan jelas. Semua yang lain dienkripsi.
— Sam Sirry
98

Saya setuju dengan jawaban sebelumnya:

Secara eksplisit:

Dengan TLS, bagian pertama URL ( https://www.example.com/ ) masih terlihat saat membangun koneksi. Bagian kedua (/ herearemygetparameters / 1/2/3/4) dilindungi oleh TLS.

Namun ada beberapa alasan mengapa Anda tidak harus memasukkan parameter dalam permintaan GET.

Pertama, sebagaimana telah disebutkan oleh orang lain: - kebocoran melalui bilah alamat browser - kebocoran melalui riwayat

Selain itu Anda memiliki kebocoran URL melalui pengarah http: pengguna melihat situs A di TLS, lalu mengklik tautan ke situs B. Jika kedua situs berada di TLS, permintaan ke situs B akan berisi URL lengkap dari situs A di parameter pengarah permintaan. Dan admin dari situs B dapat mengambilnya dari file log server B.)

— Tobias
sumber
3
@ EJP Anda tidak mengerti apa yang dikatakan Tobias. Dia mengatakan bahwa jika Anda mengklik tautan di situs A yang akan membawa Anda ke situs B, maka situs B akan mendapatkan URL pengarah. Misalnya, jika Anda berada di siteA.com?u=username&pw=123123 , maka siteB.com (yang tertaut ke pada halaman siteA.com) akan menerima " siteA.com?u=username&pw=123123 " sebagai referensi URL, dikirim ke siteB.com di dalam HTTPS oleh browser. Jika ini benar, itu sangat buruk. Benarkah ini Tobias?
— trusktr
9
@ EJP, domain terlihat karena SNI yang digunakan oleh semua browser web modern. Lihat juga diagram ini dari EFF yang menunjukkan bahwa siapa pun dapat melihat domain situs yang Anda kunjungi. Ini bukan tentang visibilitas browser. Ini tentang apa yang terlihat oleh penyadap.
— Buge
10
@trusktr: Browser tidak boleh mengirim tajuk Referer dari halaman HTTPS. Ini adalah bagian dari spesifikasi HTTP .
— Martin Geisler
8
@ MartinGeisler, Kata Kunci adalah "harus". Browser tidak terlalu peduli tentang "harus" (sebagai lawan "harus"). Dari tautan Anda sendiri: "sangat disarankan agar pengguna dapat memilih apakah bidang Perujuk dikirim atau tidak. Misalnya, klien browser dapat memiliki sakelar sakelar untuk menjelajah secara terbuka / anonim, yang masing-masing akan mengaktifkan / menonaktifkan pengiriman Referer dan Dari informasi " . Ops, yang persis seperti yang dilakukan Chrome. Kecuali Chrome membocorkan Referer bahkan jika Anda dalam mode penyamaran .
— Pacerier
48

Tambahan untuk jawaban bermanfaat dari Marc Novakowski - URL disimpan dalam log di server (misalnya, di / etc / httpd / logs / ssl_access_log), jadi jika Anda tidak ingin server mempertahankan informasi lebih lama istilah, jangan taruh di URL.

— Rhodri Cusack
sumber
34

Iya dan tidak.

Bagian alamat server TIDAK dienkripsi karena digunakan untuk mengatur koneksi.

Ini mungkin berubah di masa depan dengan SNI dan DNS terenkripsi tetapi pada 2018 kedua teknologi tidak umum digunakan.

Jalur, string kueri, dll. Dienkripsi.

Catatan untuk permintaan GET, pengguna masih dapat memotong dan menempelkan URL keluar dari bilah lokasi, dan Anda mungkin tidak ingin memasukkan informasi rahasia di sana yang dapat dilihat oleh siapa pun yang melihat layar.

— Kotak sabun
sumber
8
Ingin memberi ini +1, tetapi saya menemukan kesalahan "ya dan tidak" - Anda harus mengubahnya agar hanya menunjukkan bahwa nama server akan diselesaikan menggunakan DNS tanpa enkripsi.
— Lawrence Dol
7
Dalam pemahaman saya, OP menggunakan kata URL dalam arti yang benar. Saya pikir jawaban ini lebih menyesatkan, karena tidak jelas membuat perbedaan antara nama host di URL dan nama host dalam resolusi DNS.
— Guillaume
4
URL dienkripsi. Setiap aspek dari transaksi HTTP dienkripsi. Bukan hanya 'segalanya'. Titik. -1.
— Marquis of Lorne
4
@ EJP tetapi pencarian DNS tidak menggunakan apa yang ada di satu titik bagian dari URL, jadi untuk orang non-teknis, seluruh URL tidak dienkripsi. Orang non-teknis yang hanya menggunakan Google.com untuk mencari hal-hal non-teknis tidak tahu di mana data pada akhirnya berada atau bagaimana penanganannya. Domain, yang merupakan bagian dari URL yang dikunjungi pengguna, tidak dienkripsi 100% karena saya sebagai penyerang dapat mengendus situs mana yang ia kunjungi. Hanya path / dari URL yang dienkripsi secara inheren ke orang awam (tidak peduli bagaimana).
— trusktr
6
@ EJP, @ trusktr, @ Lawrence, @ Guillaume. Kalian semua salah. Ini tidak ada hubungannya dengan DNS. SNI " kirim nama domain virtual sebagai bagian dari negosiasi TLS ", jadi walaupun Anda tidak menggunakan DNS atau jika DNS Anda dienkripsi, sniffer masih dapat melihat nama host dari permintaan Anda.
— Pacerier
9

Pihak ketiga yang memantau lalu lintas juga dapat menentukan halaman yang dikunjungi dengan memeriksa lalu lintas Anda dan membandingkannya dengan lalu lintas yang dimiliki pengguna lain ketika mengunjungi situs tersebut. Misalnya, jika hanya ada 2 halaman di sebuah situs, satu jauh lebih besar dari yang lain, maka perbandingan ukuran transfer data akan memberi tahu halaman mana yang Anda kunjungi. Ada cara-cara ini bisa disembunyikan dari pihak ketiga tetapi mereka bukan perilaku server atau browser normal. Lihat misalnya makalah ini dari SciRate, https://scirate.com/arxiv/1403.0297 .

Secara umum jawaban lain benar, meskipun makalah ini menunjukkan bahwa halaman yang dikunjungi (yaitu URL) dapat ditentukan dengan cukup efektif.

— pbhj
sumber
Itu benar-benar hanya layak pada situs yang sangat kecil, dan dalam kasus tersebut, tema / nada / sifat situs mungkin masih akan hampir sama di setiap halaman.
— Cameron
5
Dari kutipan yang saya berikan: "Kami menyajikan serangan analisis lalu lintas terhadap lebih dari 6000 halaman web yang mencakup penyebaran HTTPS dari 10 situs web terkemuka di industri di berbagai bidang seperti kesehatan, keuangan, layanan hukum dan streaming video. Serangan kami mengidentifikasi setiap halaman di situs web yang sama dengan akurasi 89% [...] ". Tampaknya kesimpulan Anda tentang kelayakan itu salah.
— pbhj
2
Bagi siapa pun yang tertarik membaca lebih lanjut tentang kerentanan semacam ini, jenis serangan ini umumnya disebut serangan sisi-saluran .
— Dan Bechard
7

Anda tidak dapat selalu mengandalkan privasi dari URL lengkap. Misalnya, seperti yang kadang-kadang terjadi pada jaringan perusahaan, perangkat yang disediakan seperti PC perusahaan Anda dikonfigurasikan dengan sertifikat root "tepercaya" tambahan sehingga browser Anda dapat secara diam-diam mempercayai proxy (man-in-the-middle) inspeksi lalu lintas https traffic . Ini berarti bahwa URL lengkap dibuka untuk diperiksa. Ini biasanya disimpan ke log.

Selain itu, kata sandi Anda juga terbuka dan mungkin dicatat dan ini adalah alasan lain untuk menggunakan kata sandi satu kali atau untuk sering mengubah kata sandi Anda.

Akhirnya, konten permintaan dan respons juga diekspos jika tidak dienkripsi.

Salah satu contoh pengaturan inspeksi dijelaskan oleh Checkpoint di sini . "Kafe internet" gaya lama menggunakan PC yang disediakan juga dapat diatur dengan cara ini.

— Don Gillis
sumber
6

Menautkan ke jawaban saya pada pertanyaan duplikat . URL tidak hanya tersedia dalam riwayat browser, sisi server mencatat tetapi juga dikirim sebagai tajuk Pengarah HTTP yang jika Anda menggunakan konten pihak ketiga, mengekspos URL ke sumber di luar kendali Anda.

— JoshBerke
sumber
Memberikan panggilan pihak ketiga Anda adalah HTTPS juga meskipun ini bukan masalah kan?
— Liam
3
Itu akan dienkripsi dengan sertifikat pihak ketiga sehingga mereka bisa melihat URL
— JoshBerke
5

Sekarang 2019 dan TLS v1.3 telah dirilis. Menurut Cloudflare, SNI dapat dienkripsi berkat TLS v1.3. Jadi, aku berkata pada diriku sendiri hebat! mari kita lihat tampilannya dalam paket TCP cloudflare.com Jadi, saya menangkap paket handshake "klien halo" dari respons server cloudflare menggunakan Google Chrome sebagai browser & wireshark sebagai sniffer paket. Saya masih dapat membaca nama server dalam teks biasa di dalam paket Halo halo.

masukkan deskripsi gambar di sini

Jadi, waspadalah terhadap apa yang dapat Anda baca karena ini masih bukan koneksi anonim. Middleware antara klien dan server bisa mencatat setiap domain yang diminta oleh klien.

Jadi sepertinya enkripsi SNI membutuhkan implementasi tambahan untuk bekerja bersama dengan TLSv1.3

Artikel berikut menjelaskan enkripsi SNI yang disediakan oleh Cloudflare sebagai bagian dari TLSv1.3. Namun, semua URL HTTP dari cloudflare.com dalam teks biasa dalam paket TCP di bawah TLS v1.3

[ https://blog.cloudflare.com/encrypted-sni/[[3]

— Nicolas Guérinet
sumber
"SNI dapat dienkripsi" - itulah poin utamanya. Memeriksa cloudflare.com/ssl/encrypted-sni dengan Google Chrome saat ini mengatakan "Browser Anda tidak mengenkripsi SNI saat mengunjungi halaman ini." Dibutuhkan dua orang untuk
— menari
Rupanya Firefox saat ini dapat melakukan ESNI, tetapi dinonaktifkan secara default: Anda harus mengaktifkan network.security.esni.enabled, atur network.trr.modeke 2 (yang saat ini mengatur resolver DoH Anda ke CloudFlare), dan restart browser (sic!); maka akan menggunakan ESNI - di mana didukung oleh infrastruktur domain. Lihat blog.mozilla.org/security/2018/10/18/… untuk detailnya.
— Piskvor meninggalkan gedung
2

Meskipun sudah ada beberapa jawaban bagus di sini, kebanyakan dari mereka berfokus pada navigasi browser. Saya menulis ini pada 2018 dan mungkin seseorang ingin tahu tentang keamanan aplikasi seluler.

Untuk aplikasi seluler , jika Anda mengontrol kedua ujung aplikasi (server dan aplikasi), selama Anda menggunakan HTTPS, Anda aman . iOS atau Android akan memverifikasi sertifikat dan mengurangi kemungkinan serangan MiM (itu akan menjadi satu-satunya titik lemah dalam semua ini). Anda dapat mengirim data sensitif melalui koneksi HTTPS yang akan dienkripsi selama transportasi . Hanya aplikasi Anda dan server akan tahu parameter apa pun yang dikirim melalui https.

Satu-satunya "mungkin" di sini adalah jika klien atau server terinfeksi dengan perangkat lunak berbahaya yang dapat melihat data sebelum dibungkus dalam https. Tetapi jika seseorang terinfeksi dengan perangkat lunak semacam ini, mereka akan memiliki akses ke data, apa pun yang Anda gunakan untuk mengangkutnya.

— Ricardo BRGWeb
sumber
1

Selain itu, jika Anda sedang membangun API RESTful, kebocoran peramban dan masalah perujuk http sebagian besar dimitigasi karena klien mungkin bukan peramban dan Anda mungkin tidak memiliki orang yang mengklik tautan.

Jika demikian, saya akan merekomendasikan login oAuth2 untuk mendapatkan token pembawa. Dalam hal ini satu-satunya data sensitif akan menjadi kredensial awal ... yang mungkin harus tetap dalam permintaan pos

— Chris Rutledge
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.