Apakah browser web men-cache sertifikat SSL?


26

Apakah ada browser web yang menyimpan sertifikat server SSL? Misalnya, jika saya mengubah sertifikat SSL pada server web, apakah semua browser web akan mengambil sertifikat baru ketika mereka terhubung melalui SSL, atau mungkinkah mereka memiliki sertifikat yang sudah basi?

Saya sedang memikirkan skenario ketika sertifikat SSL kedaluwarsa dan diganti dengan yang baru di server web.


Saya akan berasumsi browser memeriksa tanggal pada sertifikat untuk melihat apakah perlu mendapatkan yang lebih baru, seperti halnya untuk yang lain tetapi saya tidak yakin.
soandos


1
Pada 2019, Chrome 75 saya melakukan caching sertifikat SSL
Fabian Thommen

Jawaban:


10

Jawaban dari RedGrittyBrick benar, tetapi tidak benar-benar menjawab pertanyaan. Pertanyaannya adalah, apakah browser melakukannya, bukan apakah mereka harus atau perlu melakukannya.

Dari apa yang saya dengar, baik MSIE dan Chrome benar-benar melakukan sertifikat cache, dan jangan menggantinya ketika mereka mendapatkan versi baru selama yang lama valid. Mengapa mereka melakukan ini bukan untuk saya mengerti, karena menurunkan keamanan.


Jawaban yang saat ini diterima cukup jelas. Ini secara khusus menunjukkan bahwa, tidak , browser tidak men-cache sertifikat. Saat Anda menunjukkan lanskap berubah, alasan Chrome melakukannya, didokumentasikan dengan baik akan menyenangkan bagi Anda untuk menautkan ke alasan itu. Karena sertifikat masih valid, sertifikat itu tidak "menurunkan" keamanan yang tidak masuk akal.
Ramhound

3
Itu menurunkannya, karena Anda tidak dapat mengganti kunci SHA-1 yang lama dengan yang lebih baru, karena yang lama masih valid, dan Chrome mengabaikan yang baru, jika saya mengerti semuanya dengan benar. Jadi tidak ada cara untuk menegakkan peralihan ke standar keamanan yang lebih tinggi - sehingga "lebih rendah" dalam arti relatif dengan tidak memungkinkan untuk mendorongnya lebih tinggi. Sama seperti inflasi tidak menurunkan nilai uang Anda, tetapi nilai pasar sebenarnya.
tuexss

5
+1 Setelah StartSSL memadukan kegagalan berantai SHA1 / SHA2 , jelas bahwa Chrome pada Windows memang caching sertifikat menengah, mungkin tanpa batas waktu. Chrome akan mengabaikan sertifikat perantara baru yang dikirim oleh server. Tidak jelas apakah caching dikunci oleh identitas server cert atau identitas perantara dan apa sebenarnya yang membentuk identitas itu.
Robert Važan

3
tekan masalah hari ini, baik chrome dan firefox menunjukkan sertifikat berbeda di jendela normal (sertifikat lama) dan mode penyamaran (yang benar). Utilitas baris perintah seperti curl atau openssl melaporkan sertifikat yang benar tentu saja. Diperbaiki dengan menghapus cache browser (ctrl + shift + del) - "cookie dan data situs lainnya" untuk chrome dan "data situs web offline" untuk firefox.
anilech

1
Setidaknya versi Firefox (66.0) saat ini di OSX tampaknya memegang cache itu cukup kuat. Kemarin saya telah memperbarui sertifikat TLS untuk situs web saya dan baik CLI opensslmaupun Chromium menunjukkan kepada saya sertifikat baru. Firefox menunjukkan kepada saya yang lama meskipun memuat ulang dengan cache dinonaktifkan, membersihkan semua cache dan data offline dan browser restart.
Tad Lispy

20

Tidak. Lihat ikhtisar IBM SSL

  1. Klien SSL mengirimkan pesan "halo klien" yang mencantumkan informasi kriptografis seperti versi SSL dan, dalam urutan preferensi klien, CipherSuites didukung oleh klien. Pesan itu juga berisi string byte acak yang digunakan dalam perhitungan selanjutnya. Protokol SSL memungkinkan "halo klien" untuk memasukkan metode kompresi data yang didukung oleh klien, tetapi implementasi SSL saat ini biasanya tidak termasuk ketentuan ini.

  2. Server SSL merespons dengan pesan "server halo" yang berisi CipherSuite yang dipilih oleh server dari daftar yang disediakan oleh klien SSL, ID sesi dan string byte acak lainnya. Server SSL juga mengirimkan sertifikat digitalnya . Jika server memerlukan sertifikat digital untuk otentikasi klien, server mengirim "permintaan sertifikat klien" yang mencakup daftar jenis sertifikat yang didukung dan Nama Pembeda dari Otoritas Sertifikasi (CA) yang dapat diterima.

  3. Klien SSL memverifikasi tanda tangan digital pada sertifikat digital server SSL dan memeriksa apakah CipherSuite yang dipilih oleh server dapat diterima.

...

Ringkasan Microsoft serupa. Jabat tangan TLS juga serupa dalam hal ini.

Pada langkah 2 tampaknya tidak ada cara bagi klien untuk mengatakan "jangan repot-repot mengirim sertifikat server, saya akan menggunakan cache saya".

Perhatikan bahwa ada beberapa jenis sertifikat, klien, server dan CA. Beberapa di antaranya di-cache.


Mengubah pertanyaan awal untuk menjelaskan bahwa ini adalah sertifikat server.
Lorin Hochstein

Ini tidak benar, dan dengan asumsi tidak ada cache karena tinjauan umum tentang cara kerja SSL mengecualikan caching adalah pembenaran yang sangat buruk. youtube.com/watch?v=wMFPe-DwULM
Evan Carroll

Satu-satunya cache yang dapat digunakan adalah untuk pemeriksaan validitas, meskipun itu adalah trade-off keamanan.
Daniel B

0

Saya tidak yakin apakah input saya akan membantu dengan cara apa pun, tetapi inilah yang baru saja saya alami: Saya punya situs web berwarna biru dengan domain khusus. Saya mencoba mengaksesnya dengan https di chromes sebelum mengkonfigurasi pengikatan SSL untuk nama domain saya. Chrome memberi tahu saya bahwa situs tersebut tidak diamankan yang masuk akal (ERR_CERT_COMMON_NAME_INVALID) Tetapi setelah saya mengunggah sertifikat saya dan mengkonfigurasi pengikatan SSL dengan warna biru saya masih mendapatkan kesalahan yang sama. Pada tahap ini, ketika membuka jendela browser pribadi baru (atau menggunakan browser lain) https berfungsi dengan baik.

Tapi saya tidak pernah bisa menggunakannya di sesi Chrome terbuka saya. Saya mencoba menghapus status SSL, hasil yang sama. Ini bekerja setelah memulai ulang chrome sama sekali.

Saya mungkin ditipu oleh sesuatu tetapi hampir tampak bahwa sertifikat itu di-cache ...


Kesalahan itu akan menyiratkan bahwa Anda mengakses situs dengan URI yang berbeda dari apa yang ada di CN. Apakah Anda benar-benar mengubah URI untuk mengakses situs dalam chrome setelah Anda menyiapkan ikatan?
Seth

tidak, satu-satunya hal yang saya ubah pada saat itu adalah pengikatan. Ketika saya pertama kali mempertanyakan https itu disajikan menggunakan sertifikat azure ssl default tetapi masih melayani saya yang satu ini setelah saya mengubah ikatan dengan cert yang benar di Azure.
Etienne

Seperti yang Anda katakan Anda mengkonfigurasi ikatan domain SSL Anda, apakah itu berarti Anda mengakses server menggunakan domain Anda sejak awal atau tidak? Kesalahan akan menunjukkan bahwa ada perbedaan antara URL yang Anda gunakan dan URL untuk sertifikasi itu. Itu yang saya maksud. Selain itu konfigurasi server Anda yang sebenarnya bisa sangat berarti jika Anda berpikir tentang HSTS dan semacamnya.
Seth

1
Langkah 1: situs web yang diterbitkan menjadi biru. Pada tahap ini memiliki URL biru default dan sertifikat default. Langkah 2: setup domain khusus untuk aplikasi web, sekarang mysite.com dengan benar menunjuk ke situs. Sertifikat SSL untuk mysite.com tidak dikonfigurasikan pada tahap ini. Langkah 3: Pada titik ini, ketika mencoba untuk https situs, saya mendapatkan kesalahan keamanan dengan mengatakan bahwa sertifikat tidak cocok (dan itu masuk akal) Langkah 4: Saya menginstal sertifikat SSL untuk Mysite.com dalam warna biru dan MASIH peringatan keamanan muncul dari Chrome. JANGAN terjadi di browser lain atau jika saya membuka nav pribadi.
Etienne

1
Langkah 5: Saya memulai ulang Chrome dan sekarang (dan hanya sekarang) adalah situs web saya yang dilayani menggunakan sertifikat SSL yang benar. Oleh karena itu kesimpulan saya adalah bahwa memang ada masalah caching sertifikat
Etienne

-1

Ada rencana beberapa pengembang peramban untuk menerapkan sistem chaching untuk mendeteksi serangan seperti serangan terhadap Diginotar pada 2011.

Tetapi pada saat ini AFAIK tidak ada sistem yang aktif di browser saat ini. Karenanya Anda tidak perlu memikirkan situasi ini saat memperbarui sertifikat server Anda.

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.