Kursus MIT "Keamanan Sistem Komputer". Kuliah 14: "SSL dan HTTPS", bagian 2

Institut Teknologi Massachusetts. Kursus Kuliah # 6.858. "Keamanan sistem komputer." Nikolai Zeldovich, James Mickens. Tahun 2014

Keamanan Sistem Komputer adalah kursus tentang pengembangan dan implementasi sistem komputer yang aman. Ceramah mencakup model ancaman, serangan yang membahayakan keamanan, dan teknik keamanan berdasarkan pada karya ilmiah terbaru. Topik meliputi keamanan sistem operasi (OS), fitur, manajemen aliran informasi, keamanan bahasa, protokol jaringan, keamanan perangkat keras, dan keamanan aplikasi web.

Kuliah 1: “Pendahuluan: model ancaman” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 2: "Kontrol serangan hacker" Bagian 1 / Bagian 2 / Bagian 3
Kuliah 3: “Buffer Overflows: Exploits and Protection” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 4: “Pemisahan Hak Istimewa” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 5: "Dari mana sistem keamanan berasal?" Bagian 1 / Bagian 2
Kuliah 6: “Peluang” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 7: “Kotak Pasir Klien Asli” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 8: “Model Keamanan Jaringan” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 9: "Keamanan Aplikasi Web" Bagian 1 / Bagian 2 / Bagian 3
Kuliah 10: “Eksekusi simbolik” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 11: “Bahasa Pemrograman Web / Web” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 12: Keamanan Jaringan Bagian 1 / Bagian 2 / Bagian 3
Kuliah 13: "Protokol Jaringan" Bagian 1 / Bagian 2 / Bagian 3
Kuliah 14: "SSL dan HTTPS" Bagian 1 / Bagian 2 / Bagian 3

Alasan pertama adalah bahwa protokol OCSP menambahkan penundaan untuk setiap permintaan yang Anda buat. Setiap kali Anda ingin terhubung ke server, pertama-tama Anda harus terhubung ke OCSP, tunggu sampai merespons, dan kemudian lakukan sesuatu yang lain. Jadi penundaan koneksi tidak berkontribusi pada popularitas protokol ini.

Alasan kedua adalah Anda tidak ingin OCSP memengaruhi kemampuan Anda untuk menjelajahi web. Misalkan server OSCP sedang down, dan Anda dapat kehilangan Internet sama sekali, karena protokol menganggap itu karena tidak dapat memverifikasi sertifikat seseorang, maka mungkin semua situs di Internet buruk dan Anda tidak boleh pergi ke sana. Tapi tidak ada yang membutuhkan ini, sehingga sebagian besar pelanggan melihat server OCSP non-gangguan sebagai perkembangan positif.



Ini benar-benar buruk dari sudut pandang keamanan. Karena jika Anda seorang penyerang dan ingin meyakinkan seseorang bahwa Anda memiliki sertifikat yang sah, tetapi dalam kenyataannya sertifikat ini telah dicabut, yang perlu Anda lakukan adalah mencegah klien berkomunikasi dengan server OCSP.

Klien akan mengatakan ini: "Saya mencoba untuk meminta verifikasi sertifikat dari situs yang saya butuhkan, tetapi OCSP ini, tampaknya, tidak ada di dekatnya, jadi saya pergi ke situs ini." Jadi menggunakan OCSP bukanlah rencana yang bagus.

Dalam praktiknya, orang mencoba menciptakan alternatif ini, karena pelanggan cenderung membuat kesalahan serius. Jadi, misalnya, browser web Chrome dikirimkan ke klien, sudah memiliki daftar sertifikat yang ingin dicabut oleh Google. Jadi, jika seseorang salah mengeluarkan sertifikat untuk Gmail atau situs penting lainnya, seperti Facebook atau Amazon, maka versi Chrome berikutnya sudah akan berisi informasi ini dalam daftar verifikasi bawaan. Dengan cara ini Anda tidak perlu mengakses server CRL dan berkomunikasi dengan OCSP. Jika browser telah memverifikasi bahwa sertifikat tidak lagi valid, klien menolaknya.

Siswa: misalkan saya mencuri kunci rahasia CA, karena tidak semua kunci publik dienkripsi?

Profesor: ya, ini akan memiliki konsekuensi buruk. Saya kira tidak ada solusi untuk masalah ini. Tentu saja, ada situasi ketika otoritas sertifikasi dikompromikan, misalnya, pada 2011 ada dua CA yang dikompromikan yang entah bagaimana mengeluarkan sertifikat untuk Gmail, Facebook dan sebagainya. Tidak jelas bagaimana ini terjadi, mungkin seseorang benar-benar mencuri kunci rahasia mereka. Tetapi terlepas dari alasan kompromi tersebut, CA ini telah dihapus dari daftar otoritas sertifikat tepercaya, yang dibangun di browser, sehingga mereka tidak lagi dalam rilis Chrome berikutnya.

Bahkan, ini menyebabkan masalah bagi pemegang sah sertifikat yang dikeluarkan oleh pusat-pusat ini, karena sertifikat sebelumnya menjadi tidak valid dan mereka harus mendapatkan sertifikat baru. Jadi dalam praktiknya, semua keributan dengan sertifikat ini agak membingungkan.

Jadi, kami telah memeriksa prinsip umum sertifikat. Mereka lebih baik daripada Kerberos dalam arti bahwa Anda tidak lagi membutuhkan orang ini untuk online setiap saat. Selain itu, mereka lebih scalable, karena Anda dapat memiliki beberapa KDC dan Anda tidak perlu berkomunikasi dengan mereka setiap kali Anda membuat koneksi.

Fitur lain yang menarik dari protokol ini adalah bahwa tidak seperti Kerberos, Anda tidak diharuskan untuk mengautentikasi kedua sisi koneksi. Anda dapat terhubung ke server web tanpa memiliki sertifikat sendiri, dan ini terjadi setiap saat. Jika Anda pergi ke amazon.com, maka Anda akan memeriksa bahwa Amazon adalah situs yang tepat, tetapi Amazon tidak tahu siapa Anda dan tidak akan mengetahuinya sampai Anda mengautentikasi ke situs tersebut. Dengan demikian, pada tingkat protokol enkripsi Anda tidak memiliki sertifikat, tetapi Amazon memilikinya.

Ini jauh lebih baik daripada Kerberos, karena di sana Anda harus memiliki entri dalam databasenya agar dapat terhubung ke layanan Kerberos. Satu-satunya ketidaknyamanan menggunakan protokol ini adalah bahwa server harus memiliki sertifikat. Jadi Anda tidak dapat terhubung ke server dan berkata, "hei, mari kita mengenkripsi barang-barang kami. Saya tidak tahu siapa Anda, tetapi Anda tidak tahu siapa saya, tetapi mari kita enkripsi juga. ” Ini disebut enkripsi oportunistik, dan tentu saja, ia rentan terhadap serangan manusia-di-tengah. Anda dapat mengenkripsi hal-hal umum dengan seseorang, tanpa mengenalnya, maka penyerang yang bersiap untuk menyerang Anda juga dapat mengenkripsi paket-paketnya dan melindungi dirinya dari pengintaian.

Sayang sekali protokol-protokol ini yang kami pertimbangkan di sini - SSL, TLS - tidak menawarkan enkripsi oportunistik semacam ini. Tapi begitulah hidup.



Mahasiswa: Saya hanya ingin tahu. Katakan saja setahun sekali, mereka menciptakan pasangan kunci dengan nama baru. Mengapa tidak mencoba menggunakan kunci khusus ini sepanjang tahun?

Profesor: Saya pikir mereka melakukannya. Tapi sepertinya ada yang salah dengan sirkuit ini. Di sini, seperti halnya Kerberos, orang mulai dengan menggunakan enkripsi yang kuat, tetapi seiring waktu semakin buruk dan semakin buruk. Komputer menjadi lebih cepat, algoritma baru sedang dikembangkan yang berhasil memecahkan enkripsi ini. Dan jika orang tidak peduli untuk meningkatkan keandalan, masalah tumbuh. Jadi, misalnya, itu terjadi ketika sejumlah besar sertifikat ditandatangani.

Ada dua nuansa di sini. Ada skema tanda tangan kunci publik. Lebih lanjut, mengingat bahwa kunci publik terenkripsi memiliki beberapa batasan, ketika menandatangani pesan, pada kenyataannya, hanya hash dari pesan ini yang ditandatangani, karena sulit untuk menandatangani pesan raksasa, tetapi mudah untuk menandatangani hash kompak.

Masalah muncul karena orang menggunakan MD5 sebagai fungsi hash, mengubah penandatanganan pesan besar menjadi hal 128-bit yang dienkripsi. Mungkin MD5 baik 20 tahun yang lalu, tetapi seiring waktu, orang menemukan kelemahan di dalamnya yang bisa dimanfaatkan oleh penyerang.

Misalkan pada titik tertentu seseorang benar-benar meminta sertifikat dengan hash MD5 tertentu, dan kemudian dengan hati-hati mem-parsing pesan lain yang hash dengan nilai MD5 yang sama. Akibatnya, ia memiliki tanda tangan CA hash, dan kemudian pesan lain muncul, atau kunci yang berbeda, atau nama yang berbeda, dan sekarang ia dapat meyakinkan seseorang bahwa itu ditandatangani dengan sertifikat yang benar. Dan ini benar-benar terjadi. Misalnya, jika Anda menghabiskan banyak waktu mencoba memecahkan satu kunci, pada akhirnya Anda akan berhasil. Jika sertifikat ini menggunakan enkripsi, ia dapat dipecahkan menggunakan metode brute-force.

Contoh lain dari penggunaan enkripsi yang gagal adalah algoritma RSA. Kami tidak berbicara tentang RSA, tetapi RSA adalah salah satu dari sistem kriptografi kunci publik yang memungkinkan Anda untuk mengenkripsi dan menandatangani pesan. Saat ini Anda dapat menghabiskan banyak uang, tetapi pada akhirnya, memecahkan kunci RSA 1000-bit. Anda mungkin harus melakukan sejumlah besar pekerjaan, tetapi ini mudah dilakukan sepanjang tahun. Anda dapat meminta otoritas sertifikasi untuk menandatangani pesan atau bahkan mengambil kunci publik seseorang yang sudah ada, mencoba menemukan kunci rahasia yang sesuai untuknya, atau secara manual meretasnya.
Jadi, Anda harus mengikuti penyerang, Anda harus menggunakan kunci RSA yang lebih besar atau menggunakan skema enkripsi yang berbeda.

Misalnya, sekarang orang tidak menggunakan hash dan sertifikat MD5. Mereka menggunakan algoritma hashing kriptografi SHA-1. Untuk beberapa waktu itu memberikan keamanan yang diperlukan, tetapi hari ini pertahanannya lemah. Sekarang Google secara aktif berusaha memaksa pengembang web dan browser untuk meninggalkan penggunaan SHA-1 dan menggunakan fungsi hash yang berbeda, karena cukup jelas bahwa, mungkin setelah 5 atau 10 tahun tidak akan sulit untuk berhasil menyerang SHA-1. Kelemahannya sudah terbukti.

Jadi, saya kira, peluru ajaib seperti itu tidak ada. Anda hanya perlu memastikan bahwa Anda terus berkembang secara paralel dengan para peretas. Tentu saja, masalahnya ada. Karena itu, semua hal yang kita bicarakan harus didasarkan pada enkripsi yang tepat, atau pada kenyataan bahwa itu sangat sulit untuk dipecahkan. Karena itu, Anda harus memilih opsi yang sesuai. Setidaknya ada tanggal kedaluwarsa, jadi lebih baik memilih tanggal kedaluwarsa 1 tahun, bukan 10 tahun.



Kunci CA ini menciptakan masalah yang lebih serius, karena tidak memiliki tanggal kedaluwarsa. Oleh karena itu, Anda harus memilih pengaturan keamanan yang lebih agresif, misalnya, kunci RSA 4000 atau 6000 bit, atau yang lainnya. Atau skema enkripsi yang berbeda, atau semuanya bersama-sama, tetapi jangan gunakan SHA-1 di sini.

Sekarang mari kita lihat bagaimana kita mengintegrasikan protokol ini ke dalam aplikasi tertentu, yaitu browser web. Jika Anda ingin memberikan komunikasi jaringan atau komunikasi dengan situs menggunakan kriptografi, ada tiga hal di browser yang harus kita lindungi.

Hal pertama, A adalah perlindungan data di jaringan. Ini relatif mudah karena kita hanya akan menjalankan protokol yang sangat mirip dengan yang saya jelaskan sejauh ini. Kami akan mengenkripsi semua pesan, menandatanganinya, memastikan bahwa mereka belum dirusak, secara umum, kami akan melakukan semua hal indah ini. Inilah cara kami akan melindungi data.

Tetapi ada dua hal lagi di browser web yang benar-benar perlu kita khawatirkan. Jadi, yang pertama, B, adalah kode yang digunakan di browser, misalnya, JavaScript atau data penting yang disimpan di browser, cookie Anda, atau penyimpanan lokal, semua ini entah bagaimana harus dilindungi dari peretas. Sebentar lagi saya akan memberi tahu Anda cara melindungi mereka.

Yang terakhir, C, yang sering tidak Anda pikirkan, tetapi yang mungkin menjadi masalah nyata dalam praktik, adalah perlindungan antarmuka pengguna. Dan alasan untuk ini adalah, pada akhirnya, sebagian besar data rahasia yang kami pedulikan tentang perlindungan berasal dari pengguna. Jadi, pengguna mencetak data di beberapa situs, dan dia mungkin memiliki beberapa tab situs berbeda yang terbuka secara bersamaan, jadi dia harus dapat membedakan situs mana dia sebenarnya berinteraksi, pada waktu tertentu.



Jika dia secara tidak sengaja memasukkan kata sandi Amazon di beberapa forum web, ini tidak akan menyebabkan konsekuensi yang membahayakan, tergantung pada seberapa besar dia peduli dengan kata sandi Amazon-nya, tetapi tetap saja itu tidak menyenangkan. Oleh karena itu, Anda benar-benar ingin memiliki antarmuka pengguna yang baik yang membantu pengguna memahami apa yang dia lakukan, apakah ia mencetak data sensitif di situs yang tepat dan jika sesuatu terjadi pada data ini setelah ia mengirimkannya. Jadi ini ternyata menjadi masalah yang cukup penting untuk melindungi aplikasi web.

Jadi, mari kita bicara tentang apa yang browser modern lakukan dengan hal-hal A, B, dan C. Seperti yang saya sebutkan, untuk melindungi data di jaringan, kami hanya akan menggunakan protokol ini, yang disebut SSL atau TLS, jika enkripsi dan otentikasi data digunakan.



Ini sangat mirip dengan apa yang kita diskusikan, dan termasuk otoritas sertifikat dan sebagainya. Dan tentu saja, ada banyak detail lainnya. Misalnya, TLS sangat kompleks, tetapi kami tidak akan mempertimbangkannya dari sudut pandang ini. Kami akan fokus pada perlindungan browser, yang jauh lebih menarik. Kita perlu memastikan bahwa setiap kode atau data yang dikirim melalui koneksi tidak terenkripsi tidak mampu mengubah kode dan data yang diterima dari koneksi terenkripsi, karena model ancaman kita adalah sedemikian rupa sehingga semua data yang tidak terenkripsi dapat dirusak oleh penyerang melalui jaringan.

Jadi jika kita memiliki semacam kode JavaScript yang tidak terenkripsi yang berjalan di browser kita, kita harus mengasumsikan bahwa itu bisa dirusak oleh penyerang karena tidak dienkripsi. Itu tidak mengautentikasi melalui jaringan. Dan, oleh karena itu, kita harus mencegah interferensi dari halaman apa pun yang dikirimkan melalui koneksi yang tidak terenkripsi.

Jadi, rencana umumnya adalah untuk ini kita akan memperkenalkan skema URL baru, yang akan kita sebut HTTPS. Anda sering melihat ini di url. Skema URL baru adalah bahwa sekarang URL ini sangat berbeda dari alamat HTTP. Jadi, jika Anda memiliki URL dengan HTTPS ini: //, maka ia memiliki sumber asal yang berbeda dari URL HTTP biasa, karena yang terakhir melewati tambalan yang tidak terenkripsi, mereka pergi melalui SSL / TLS. Dengan cara ini Anda tidak akan pernah mengacaukan jenis alamat ini jika kebijakan asal yang sama berfungsi dengan benar.

Jadi ini adalah salah satu bagian dari teka-teki. Tetapi kemudian Anda juga perlu memastikan bahwa situs terenkripsi dengan benar dibedakan satu sama lain, karena untuk alasan historis mereka menggunakan kebijakan cookie yang berbeda. Jadi mari kita bicara tentang bagaimana kita akan membedakan situs terenkripsi yang berbeda satu sama lain.

Rencananya adalah nama host melalui URL harus menjadi nama dalam sertifikat. Bahkan, ternyata otoritas sertifikasi akan menandatangani nama host, yang muncul di URL sebagai nama kunci publik server web. Karena itu, Amazon diduga memegang sertifikat untuk www.amazon.com . Ini adalah nama dalam tabel kami yang memiliki kunci publik yang sesuai dengan kunci pribadi mereka.



Inilah yang akan dicari browser. Jadi jika dia menerima sertifikat, jika dia mencoba menghubungkan atau mendapatkan URL foo.com , itu berarti server secara akurat mewakili sertifikat foo.com yang asli. Kalau tidak, katakanlah, kami mencoba menghubungi satu orang, dan menghubungi yang lain, karena ia memiliki nama yang sangat berbeda dalam sertifikat yang kami sambungkan. Ini akan menjadi ketidaksesuaian sertifikat.

Inilah cara kami akan membedakan situs yang berbeda satu sama lain: kami akan membawa CA ke sini untuk membantu kami membedakan situs ini dari satu sama lain, karena CA berjanji untuk mengeluarkan sertifikat hanya untuk anggota jaringan yang tepat. Jadi ini adalah bagian dari kebijakan asal yang sama, yang menurutnya kami membagi kode menjadi beberapa bagian. Seingat Anda, cookie memiliki kebijakan yang sedikit berbeda. Mereka hampir memiliki asal yang sama, tetapi tidak sepenuhnya, cookie memiliki rencana yang sedikit berbeda. Cookie memiliki bendera keamanan yang disebut, Bendera Aman. Aturannya adalah jika cookie memiliki flag ini, maka cookie hanya dikirim sebagai respons atas permintaan HTTPS atau bersama dengan permintaan HTTPS. Cookie dengan dan tanpa bendera keamanan berhubungan satu sama lain sebagai https dan permintaan http.



Ini agak rumit. Akan lebih mudah jika cookie hanya menunjukkan bahwa itu adalah cookie untuk host HTTPS, dan itu adalah cookie untuk host HTTP, dan mereka benar-benar berbeda. Ini akan sangat jelas dalam hal mengisolasi situs aman dari yang tidak aman. Sayangnya, karena alasan historis, cookie menggunakan interaksi yang aneh ini.

Oleh karena itu, jika cookie ditandai sebagai aman, itu hanya berlaku untuk situs HTTPS, yaitu memiliki host yang benar. Cookie aman hanya berlaku untuk URL host HTTPS, sementara cookie tidak aman berlaku untuk kedua jenis URL, baik untuk https dan http, jadi hanya dalam sedetik ini akan menjadi sumber masalah bagi kami.

Dan sentuhan terakhir yang dilakukan browser web untuk mencoba membantu kami dalam hal ini adalah aspek antarmuka pengguna di mana mereka akan memasukkan semacam ikon kunci agar pengguna dapat melihatnya. Dengan demikian, Anda harus memperhatikan ikon kunci di bilah alamat browser dan URL untuk mengetahui di mana Anda sebenarnya berada.

Pengembang peramban web berharap Anda akan berperilaku seperti ini: begitu Anda masuk ke beberapa situs web, Anda pertama-tama melihat URL dan memastikan bahwa ini adalah nama host yang ingin Anda ajak bicara, dan kemudian Anda akan menemukan ikon kunci dan mengerti bahwa semuanya baik-baik saja. Ini adalah aspek antarmuka pengguna browser.

Namun, ini tidak cukup. Ternyata banyak situs phishing hanya akan menyertakan gambar ikon kunci di situs itu sendiri, tetapi menggunakan URL yang berbeda. Dan jika Anda tidak tahu apa alamat situs ini seharusnya, Anda mungkin tertipu. Dalam pengertian ini, sisi antarmuka pengguna ini agak membingungkan, sebagian karena pengguna sendiri sering bingung. Jadi sulit untuk mengatakan apa yang ada di sini. Karena itu, kami akan fokus terutama pada aspek kedua, B, yang tentu saja lebih mudah untuk dibahas. Ada pertanyaan tentang ini?



Mahasiswa: Saya perhatikan bahwa beberapa situs berubah dari waktu ke waktu dari HTTP ke HTTPS.

Profesor: ya, browser berevolusi dari waktu ke waktu, dan ini dikonfirmasi oleh fakta bahwa mereka mendapatkan ikon kunci. Beberapa browser menetapkan ikon kunci hanya jika semua konten atau semua sumber daya pada halaman Anda juga dikirimkan melalui https. Jadi salah satu masalah yang coba dipecahkan oleh HTTPS dengan paksa adalah konten campuran atau masalah dengan jenis konten tidak aman yang tertanam di halaman. Karena itu, kadang-kadang Anda tidak dapat memperoleh ikon kunci karena pemeriksaan ini. Jika browser Chrome menganggap bahwa sertifikat situs tidak cukup baik dan menggunakan kriptografi yang lemah, maka itu tidak akan memberi Anda ikon kunci. Namun, browser yang berbeda bertindak secara berbeda, dan jika Chrome tidak memberi Anda ikon kunci, maka Firefox dapat melakukannya. Jadi, sekali lagi, tidak ada definisi yang jelas tentang apa arti ikon kunci ini.

Mari kita lihat masalah apa yang mungkin timbul ketika mengimplementasikan rencana ini. Dalam HTTP biasa, kita terbiasa mengandalkan DNS, yang seharusnya memberi kita alamat IP yang benar di server. DNS HTTPS URL-? DNS DNS?

: , , , IP-.

: , , , amazon.com.

: , - amazon.com, IP-.

: , , – - DNS . , DNS , . , DNS , IP-, . , - DNS- IP-? ?

: , HTTPS?

: , , .

: , HTTP URL.

: , HTTPS, .

: .

: , . . , CA, , , , - , .

, - https , - , , , , , , .

HTTPS , - . , . , , , . -. « , ». , , , - , . , - .

, , , . , amazon.com www.amazon.com , , , .

-, , , . , : „ , , , , ». , - , . .

, DNS, , , .

, , DNS, . , DNS-, SSL / TLS HTTPS, DNS . , DNS . DoS , , .

, — , ? , , ? , ?



: , - , . , .

: , , , , , , : « »! , , - , , , , . , .

: , .

: , . . , , , , , cookies, , URL-, , origin. , - amazon.com , , , , amazon.com. , amazon.com, , , , , , JavaScript .

, , -. , . - amazon.com «» . , amazon.com, , , , . . , , .

52:10

MIT « ». 14: «SSL HTTPS», 3


.

Terima kasih telah tinggal bersama kami. Apakah Anda suka artikel kami? Ingin melihat materi yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikannya kepada teman-teman Anda, diskon 30% untuk pengguna Habr pada analog unik dari server entry-level yang kami buat untuk Anda: Seluruh kebenaran tentang VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps dari $ 20 atau bagaimana membagi server? (opsi tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps hingga Desember secara gratis ketika membayar untuk jangka waktu enam bulan, Anda dapat memesan di sini .

Dell R730xd 2 kali lebih murah? Hanya kami yang memiliki 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV dari $ 249 di Belanda dan Amerika Serikat! Baca tentang Cara Membangun Infrastruktur Bldg. kelas menggunakan server Dell R730xd E5-2650 v4 seharga 9.000 euro untuk satu sen?