Apakah tajuk HTTPS dienkripsi?

600

Saat mengirim data melalui HTTPS, saya tahu konten dienkripsi, namun saya mendengar jawaban beragam tentang apakah tajuk dienkripsi, atau seberapa banyak tajuk dienkripsi.

Berapa banyak dari HTTPS header yang dienkripsi?

Termasuk GET / URL permintaan POST, Cookie, dll.

— Dan Herbert
sumber

9

Header HTTP melalui HTTPS dienkripsi, dan juga tidak HTTP-Compressed (bahkan jika badannya). Ini membuat mereka kurang rentan terhadap serangan terkait kompresi seperti BEAST

— Neil McGuigan

552

Seluruh lot dienkripsi ^† - semua header. Itu sebabnya SSL di vhosts tidak berfungsi dengan baik - Anda memerlukan alamat IP khusus karena header Host dienkripsi.

^† Server Nama Identification (SNI) standar sarana yang hostname mungkin tidak dienkripsi jika Anda menggunakan TLS. Selain itu, apakah Anda menggunakan SNI atau tidak, tajuk TCP dan IP tidak pernah dienkripsi. (Jika ya, paket Anda tidak akan dapat dialihkan.)

— Greg
sumber

3

@Reg, Karena vhost gateway diotorisasi, tidak bisakah gateway tidak mengenkripsi mereka, amati header Host, lalu tentukan host mana yang akan dikirimi paket?

— Pacerier

2

URL afaik sendiri tidak dienkripsi.

— Teddy

4

@Teddu apa yang Anda maksud dengan "URL itu sendiri tidak dienkripsi." Dienkripsi, karena itu bagian dari header.

— Dmitry Polushkin

1

Jika Fiddler digunakan untuk menangkap komunikasi https, itu masih menampilkan beberapa tajuk, mengapa? Terutama, ketika koneksi internet melalui proxy yang memerlukan otentikasi, ini akan menampilkan header Proksi-Otorisasi ketika permintaan dikirim ulang setelah mendapat 407 pada pengiriman pertama.

— Bochen Lin

1

@Bochen seperti Pegasus. Jika Anda berada di kedua ujung terowongan HTTPS maka Anda dapat melihat semuanya. Cara yang sama saya bisa melihat apa pun di browser devtools.

— Nux

97

Header sepenuhnya dienkripsi. Satu-satunya informasi yang melewati jaringan 'in the clear' terkait dengan pengaturan SSL dan pertukaran kunci D / H. Pertukaran ini dirancang dengan hati-hati untuk tidak menghasilkan informasi yang berguna bagi penyadap, dan setelah itu terjadi, semua data dienkripsi.

— mdb
sumber

4

Tidak semua penyiapan SSL melibatkan DH

— Dori

30

Menjadi sedikit bertele-tele: Alamat IP klien dan server, nama host server, dan sinyal tentang implementasi SSL mereka berguna untuk menguping dan terlihat.

— poolie

66

Jawaban baru untuk pertanyaan lama, maaf. Saya pikir saya akan menambahkan $ 0,02 saya

OP bertanya apakah header dienkripsi.

Mereka adalah: dalam perjalanan.

Mereka TIDAK: saat tidak dalam perjalanan.

Jadi, URL browser Anda (dan judulnya, dalam beberapa kasus) dapat menampilkan querystring (yang biasanya berisi detail paling sensitif) dan beberapa detail di header; browser mengetahui beberapa informasi header (tipe konten, unicode, dll); dan riwayat peramban, manajemen kata sandi, favorit / bookmark, dan halaman dalam tembolok semua akan berisi pertanyaan tersebut. Log server pada ujung jarak jauh juga dapat berisi querystring serta beberapa detail konten.

Juga, URL tidak selalu aman: domain, protokol, dan port terlihat - jika router tidak tahu ke mana harus mengirim permintaan Anda.

Juga, jika Anda punya proxy HTTP, server proxy tahu alamatnya, biasanya mereka tidak tahu querystring lengkap.

Jadi jika data bergerak, umumnya dilindungi. Jika tidak dalam perjalanan, itu tidak dienkripsi.

Bukan untuk memilih, tetapi data pada akhirnya juga didekripsi, dan dapat diuraikan, dibaca, disimpan, diteruskan, atau dibuang sesuka hati. Dan, malware di kedua ujungnya dapat mengambil snapshot data yang masuk (atau keluar) protokol SSL - seperti Javascript (buruk) di dalam halaman di dalam HTTPS yang secara diam-diam dapat membuat panggilan http (atau https) ke situs web logging (karena akses ke harddisk lokal sering dibatasi dan tidak bermanfaat).

Cookie juga tidak dienkripsi di bawah protokol HTTPS. Pengembang yang ingin menyimpan data sensitif dalam cookie (atau di mana pun dalam hal ini) perlu menggunakan mekanisme enkripsi mereka sendiri.

Mengenai cache, sebagian besar browser modern tidak akan melakukan cache halaman HTTPS, tetapi fakta itu tidak ditentukan oleh protokol HTTPS, itu sepenuhnya tergantung pada pengembang browser untuk memastikan tidak membuat cache halaman yang diterima melalui HTTPS.

Jadi jika Anda khawatir tentang mengendus paket, Anda mungkin baik-baik saja. Tetapi jika Anda khawatir tentang malware atau seseorang yang menelusuri riwayat, bookmark, cookie, atau cache Anda, Anda belum keluar dari air.

— Andrew Jennings
sumber

20

Saya tahu jawaban yang baik ada di atas, tetapi ini sekali lagi memasukkan informasi yang salah . Domain tidak terlihat, kecuali jika SNI digunakan. Protokol, selain IP dan TCP tidak terlihat. Anda tidak dapat mengetahui apakah saya menggunakan HTTP 1.1, SPDY atau HTTP2. Apa yang terlihat pada dua titik akhir tidak relevan, karena tujuan enkripsi bukan untuk membuat hal-hal tidak terlihat tetapi untuk membuat hal-hal hanya terlihat oleh pihak yang dipercaya. Jadi titik akhir tersirat dalam pertanyaan dan sekitar 2/3 dari jawaban Anda dapat dihapus. Informasi proksi harus: jika Anda menggunakan proksi HTTPS, maka ia memiliki akses ke semuanya .

— Melvyn

6

Tautan Anda mengatakan secara spesifik bahwa cookie dienkripsi: "Koneksi pengunjung dienkripsi, mengaburkan URL, cookie, dan metadata sensitif lainnya."

— DylanYoung

1

Ya itu benar. Cookie dienkripsi saat dalam perjalanan, tetapi begitu mereka mencapai browser, mereka tidak dienkripsi oleh protokol SSL. Dimungkinkan bagi pengembang untuk mengenkripsi data cookie, tetapi itu di luar cakupan untuk SSL.

— Andrew Jennings

4

@DylanYoung SSL = lapisan soket aman ; TLS = keamanan lapisan transport . Enkripsi berada pada level socket (koneksi) atau dengan kata lain pada level transport tidak sementara disimpan di browser per basis data domain.

— curiousguy

@Wigwam Cookie HTTP sensitif yang sensitif hampir selalu merupakan referensi yang tidak jelas (biasanya nomor acak yang kuat secara kriptografis) ke catatan di database server sesi yang diautentikasi. Dengan demikian mengenkripsi pengidentifikasi tidak berarti ini sebagian besar akan membawa kompleksitas tambahan.

— curiousguy

53

HTTP versi 1.1 menambahkan metode HTTP khusus, CONNECT - dimaksudkan untuk membuat terowongan SSL, termasuk jabat tangan protokol yang diperlukan dan pengaturan kriptografi.
Permintaan reguler setelah itu semua dapat dikirim terbungkus dalam terowongan SSL, tajuk dan badan inklusif.

— Keranjingan
sumber

Kapan CONNECT digunakan untuk membuat terowongan SSL?

— curiousguy

@curiousguy tools.ietf.org/html/rfc7231#s-4-4.6

— avp

47

Dengan SSL, enkripsi berada pada level transport, sehingga terjadi sebelum permintaan dikirim.

Jadi semua yang ada dalam permintaan dienkripsi.

— blowdart
sumber

Karena SSL terjadi di lapisan transport dan penugasan alamat tujuan dalam paket (di header) terjadi di lapisan jaringan (yang di bawah transportasi), lalu bagaimana header dienkripsi?

— Prateek Joshi

@PrateekJoshi Karena header HTTP hidup pada lapisan aplikasi dan, secara default, dienkripsi karena lapisan yang lebih rendah / leluhur dienkripsi.

— Aquarelle

40

HTTPS (HTTP over SSL) mengirim semua konten HTTP melalui tunel SSL, sehingga konten HTTP dan tajuknya juga dienkripsi.

— CMS
sumber

21

Ya, tajuk dienkripsi. Itu tertulis di sini .

Segala sesuatu dalam pesan HTTPS dienkripsi, termasuk tajuk, dan beban permintaan / respons.

— penekanan tombol
sumber

37

Wikipedia bukan spec, yang harus Anda kutip.

— Aran Mulholland

8

URL juga terenkripsi, Anda benar-benar hanya memiliki IP, Port dan jika SNI, nama host yang tidak terenkripsi.

— xxiao
sumber

Bahkan jika SNI tidak didukung, perantara yang mampu mencegat koneksi HTTP akan sering juga mampu memonitor pertanyaan DNS (kebanyakan intersepsi dilakukan di dekat klien, seperti pada router pengguna bajakan). Jadi mereka akan dapat melihat nama DNS.

— curiousguy