Chuyển đến nội dung chính

HTTPS hoạt động như thế nào?

Chữ ký điện tử là cơ chế bao gồm 3 thuật toán:
  • Thuật toán chọn một khóa bí mật (private key) từ 1 tập các khóa một cách ngẫu nhiên
  • Thuật toán ký. Đầu vào là 1 thông điệp và khóa bí mật. Đầu ra là một chữ ký.
  • Thuật toán kiểm tra chữ ký. Đầu vào là một thông điệp, khóa công khai, và chữ ký. Đầu ra là đồng ý hay từ chối tính thẩm quyền của thông điệp
Do vậy để có chữ ký điện tử, ta cần có thuật toán cho phép  và kiểm tra chữ ký.
Chuyện gì sẽ xảy ra khi browser truy cập 1 site có https
Quá trình browser truy cập 1 site https có thể được mô tả bằng hình ảnh dưới đây (copy từ http://stackoverflow.com/questions/470523/how-does-ssl-really-work)
  1. Browser sẽ truy cập 1 trang web https. Ở đây là https://payment.com
  2. Server hay Load Balancer (LB) của payment.com sẽ trả về certificate để chứng thực rằng website user đang truy cập là website chính thức. Trong certificate là một public key PK, dùng để mã hóa K ở bước 4.
  3. Browser sẽ kiểm chứng certificate (bằng cách chạy thuật toán kiểm tra chữ ký). Quá trình này giúp browser xác định https://payment.com là thật hay giả.
  4. Sau khi kiểm chứng được certificate, browser sẽ tự sinh ra 1 khóa K. Khóa K sẽ được dùng để mã hóa tất cả các liên lạc giữa browser và payment.com sau này. Do quá trình mã hóa các gói tin dùng mã đối xứng, khóa K cần được gửi trở lại payment.com vì nếu không có K, server (LB) không thể nào giải mã được gói tin.
  5. Khóa K được gửi trả lại cho payment.com. Phía payment.com sẽ dùng private key (được bảo vệ) để giải mã gói tin này và qua đó có được thông tin về K.
  6. payment.com và browser dùng khóa K để mã hóa toàn bộ dữ liệu liên lạc sau này.
Certificate là một khối dữ liệu bao gồm rất nhiều thông tin về payment.com. Các thông tin này bao gồm:
  • Tên domain
  • Tên công ty sở hữu
  • Thời gian certificate được cấp
  • Thời hạn certificate
  • Public key PK
Làm thế nào browser kiểm chứng được certificate ở bước 3
Bất cứ người nào đứng giữa browser và payment.com đều có thể làm giả certificate và public key. Bằng cách làm giả certificate, người đứng giữa có thể giả dạng payment.com. Bằng cách giả public key, người đứng giữa có thể dùng khóa private của mình để xem thông tin truyển tải giữa 2 bên. Vậy làm thế nào để ngăn chặn cách tấn công này. Cách giải quyết là: CA (Certificate Authority).
CA là gì? Làm gì?
Trong thực tế, để chứng minh một ai đó trình độ đại học, trường đại học nơi người đó học sẽ cấp cho họ một tấm bằng. Do tấm bằng đó có thể bị làm giả, ta cần một đơn vị chứng minh đó là bằng thật. CA chính là người chứng minh certificate mà payment.com cung cấp là thật! CA bán dịch vụ chứng thực đó bằng cách ký chứng minh rằng certificate của payment.com là thật
Certificate chứng thực cho payment.com sẽ được CA  bằng khóa bí mật của CA. Khóa này chỉ có CA biết và do vậy việc chữ ký là an toàn. payment.com sẽ gửi cho user certificate đã được ký bởi CA cùng với khóa công khai PK2 của khóa bí mật CA dùng để ký certificate. Browser sẽ tiến hành kiểm tra certificate này như bình thường dùng khóa công khai PK2 của CA.
Đến đây vấn đề chưa thực sự được giải quyết vì, khóa công khai của CA cũng hoàn toàn có thể bị làm giả và do vậy certificate hoàn toàn có thể là giả! Giống như thực tế người chứng minh cho tấm bằng đại học cũng có thể bị làm giả. Để chắc chắn việc này, ta có thể ký chứng thực certificate do CA ký là thật. Cách làm có thể hoàn toàn tương tự là dùng khóa bí mật nào đó và ký tiếp và đính kèm khóa công khai PK3 với certificate sau khi được ký. Cứ thế ta có một dãy các certificate và khóa công khai mà certificate sau chứng thực cho certificate trước. Do bản chất đệ quy, ta cần điểm dừng là một certificate mà ta hoàn toàn tin tưởng. Đến đây ta có khái niệm root certificate.
Root certificate
Root certificate là certificate mà ta hoàn toàn tin tưởng. Khi có certificate này, ta có thể tin tưởng những certificate mà được chứng thực bởi certificate này là hoàn toàn hợp lệ (giống trong thực tế là cơ quan công chứng!). Mỗi OS và browser có một danh sách các certificate mà OS và browser đó tin tưởng.
Firefox tin tưởng các certificate có danh sách tại: https://wiki.mozilla.org/CA:IncludedCAs
RHEL có danh sách các certificate tin tưởng tại: /etc/pki/tls/certs/
Do root certificate là certificate cuối cùng dùng để chứng thực các certificate trong chuỗi, khóa bí mật của certificate này cần được bảo vệ nghiêm ngặt. Bất cứ công ty cung cấp dịch vụ CA nào bị tấn công và bị mất khóa bí mật của root certificate đều rất nguy hiểm, bởi vì hackers có thể dùng khóa đó để ký certificate ở bước cuối cùng. Do browser và OS tin tưởng certificate này nên tất cả certificate, không nhất thiết do CA bị hack cung cấp, đều có thể bị làm giả. Các CA do vậy dùng rất nhiều công sức để bảo vệ thật kín đáo khóa bí mật này. Kinh doanh chứng thực CA là kinh doanh về mặt lòng tin, CA hứa sẽ đảm bảo tốt nhất khóa bí mật của họ và ta trả tiền để họ dùng khóa bí mật của họ ký.

Bộ mật mã là gì?
A Cipher Suite là một sự kết hợp của các thuật toán được sử dụng để thương lượng các thiết lập bảo mật trong quá trình bắt tay SSL / TLS. Sau khi ClientHello và ServerHello tin nhắn được trao đổi, khách hàng sẽ gửi một danh sách ưu tiên các bộ mã hóa mà nó hỗ trợ. Máy chủ sau đó sẽ phản hồi với bộ mã hóa mà nó đã chọn từ danh sách.

Các bộ mã hóa được đặt tên là các kết hợp của:

Thuật toán trao đổi khóa (RSA, DH, ECDH, PSK)
Thuật toán xác thực (RSA, DSA)
Thuật toán mã hóa hàng loạt (AES, Camellia, ARIA)
Thuật toán mã xác thực thư (SHA-256)
Vì vậy, ví dụ, đây là một ví dụ về một bộ mã hóa:
TLS _ECDHE_ RSA _ WITH_AES_128_GCM _ SHA256

Tôi đã tô màu nó để giúp bạn phân biệt giữa các thuật toán mã hóa.
TLS là giao thức. Bắt đầu với ECDHE, chúng ta có thể thấy rằng trong quá trình bắt tay, các khóa sẽ được trao đổi qua Elliptic Curve Diffie Hellman (ECDHE) tạm thời. RSA là thuật toán xác thực. AES_128_GCM là thuật toán mã hóa hàng loạt. Cuối cùng, SHA-256 là thuật toán băm.

Hầu hết các trình duyệt và máy chủ đều có danh sách các bộ mã hóa mà chúng hỗ trợ, cả hai sẽ so sánh danh sách – theo thứ tự ưu tiên – chống lại nhau trong quá trình bắt tay để xác định cài đặt bảo mật sẽ được sử dụng.
Xem certificate chain trong thực tế
Đến đây ta chắc đã hiểu phần nào về cơ chế chứng thực cũng như cách hoạt động của HTTPS. Ta sẽ cùng xem chuỗi certificate trong thực tế.
alt text


Facebook certificate được ký bởi DigiCert High Assurance CA-3. Bản thân CA-3 được chứng thực bởi EV RootCA.
Các vấn đề liên quan đến https / certificate
Nguyên tắc hoạt động là như vậy, trong thực tế để duy trì và vận hành một hệ thống https cần tốn khá nhiều công sức. Dưới đây là một số case-studies mình gặp trong quá trình vận hành một website. Qua một số case-studies này hy vọng bạn sẽ hiểu tầm quan trọng của mỗi sự kiện và ý nghĩa của nó.
Heartbleed
Sự kiện heartbleed là sự kiện đình đám của năm 2014. Heartbleed là lỗi bảo mật nằm trong bộ thư viện OpenSSL, bộ thư viện chủ đạo xử lý mã hóa trên Linux. Các webserver đều được build sử dụng OpenSSL nếu muốn phục vụ https.
Heartbleed xảy ra khi openssl không kiểm tra độ dài trả về của một chuỗi ký tự và vô tình trả về thông tin nằm sau chuỗi ký tự này trên bộ nhớ. Vô tình phần bộ nhớ này bao gồm khóa bí mật được dùng để ký certificate ban đầu. Bằng cách hỏi máy chủ cho xem chìa khóa bí mật này, hacker có thể dùng nó để giải mã khóa mã hóa liên lạc ở bước 5 và do đó đọc được toàn bộ nội dung của phiên liên lạc.
Heartbleed nguy hiểm bởi việc tấn công này hoàn toàn không để lại dấu vết.
Các công ty cung cấp dịch vụ qua https đã phải xử lý vấn đề này bao gồm các bước sau:
  • Nâng cấp phiên bản openssl
  • Khởi động lại máy chủ web (apache, nginx)
  • Tạo một khóa bí mật mới, certificate mới và yêu cầu CAs ký lại

Diginostar

Diginostar là hãng CAs của Hà Lan bị hacker tấn công và lấy được khóa bí mật. Từ đó tất cả các root certificate của Diginostar đều bị xóa bỏ khỏi browser, do lo sợ hacker sẽ dùng khóa bí mật này làm giả certificate. Điều này dẫn đến sự phá sản của CA.
Qua đấy mới thấy việc bảo vệ khóa bí mật an toàn là vấn đề sống còn của các CAs.

Superfish

Hãng máy tính Lenovo khi bán máy tính đã cài thêm một phần mềm hiển thị quảng cáo đến người dùng. Khi người dùng lướt net, phần mềm này sẽ tự thêm một quảng cáo nhỏ trên browser. Để có thể thêm quảng cáo vào bất cứ chỗ nào, phần mềm này tự ý cài một root certificate vào máy lenovo bán đi. Root certificate này lại là một certificate tự ký, bất cứ ai có máy lenovo đều có thể có được khóa bí mật ký certificate này. Điều này vô tình biến tất cả người dùng máy lenovo thành đối tượng bị làm giả certificate. Tất cả các liên lạc https đều có thể bị làm giả, do vậy việc làm này đã tạo ra một lỗi bảo mật rất nghiêm trọng.
Hãng Lenovo sau đó đã phải xin lỗi người dùng và đưa ra phần mềm gỡ bỏ tool này.
OS quá cũ
Các root certificate đi kèm với máy chủ không phải có thời hạn mãi mãi mà được làm mới qua mỗi lần release một phiên bản của OS. Do vậy việc update OS thường xuyên là điều nên làm. Tuy vậy đối với các máy chủ làm việc bận rộn, việc nâng cấp nhiều khi là điều khó khăn. Từ đây nảy sinh một vấn đề như sau.
Máy chủ thỉnh thoảng hay phải gọi các https thông qua curl, ví dụ gọi twitter api qua https, hay gọi một dịch thanh toán nào đó qua Https. Giống như browser, curl dùng root certificate đi kèm để chứng thực các certificate phía dịch vụ gửi về. Tuy vậy khi root certificate hết hạn, việc chứng thực này sẽ thất bại, kéo theo việc app của bạn sẽ không chạy đúng nữa. Những lúc này việc update root certificate là việc cần phải làm.
Kết luận
Bài viết trình bày khái quát nguyên tắc hoạt động của https cũng như các vấn đề xoay quanh liên lạc dùng https. Hy vọng qua bài viết bạn hiểu rõ hơn về https cũng như lý giải được tầm nghiêm trọng của những vấn đề và sự kiện xoay quanh https.

Nhận xét

Bài đăng phổ biến từ blog này

HttpOnly Flag và Secure Flag của chiếc Cookie để làm gì?

Cookies rất hữu ích nhưng cũng tồn tại không ít rủi ro. Bài viết sau đây giúp tìm hiểu rõ thêm về 2 thuộc tính giúp bảo vệ Cookies là Httponly flag   và Secure flag.   Nếu anh em mò vào được bài này thì chắc cũng biết về Cookie rồi, nhưng còn hiểu lơ mơ    thì click vào đây trước nhé -  Cookie . Chuyện kể rằng, ngày xửa ngày xưa, có một "nghệ sĩ" nọ do không sao kê tiền từ thiện nên đã bị hacker tấn công chiếm rất nhiều tài khoản do bị mất cookie.  1. Tại sao lại mất?   Nguyên nhân "nghệ sĩ" bị mất thông tin cá nhân là do quá chủ quan khi click đọc email do rất nhiều "fan" gửi cho, trong những email đó có gắn đường link chứa mã độc đánh cắp cookie của 1 trang web nào đó.  Do cookies phản hồi từ server mà các đường link đó dẫn tới không được bảo vệ     nên đã bị đối tượng xấu lấy mất cookies chứa xác thực đăng nhập -> dẫn tới mất thông tin. Về mặt bản chất, cũng có thể hiểu đây như là một cuộc tấn công XSS , đối tượng gửi email sẽ execute một đoạn scri

Những câu hỏi phỏng vấn kỹ sư bảo mật thường gặp.

Dưới đây là một danh sách các câu hỏi thường được sử dụng trong việc phỏng vấn tuyển dụng chuyên gia bảo mật. Nhiều câu hỏi được thiết kế buộc người được phỏng vấn phải suy nghĩ, và không thể chuẩn bị trước cho dạng câu hỏi này. Ở đó, các phản ứng của ứng viên cũng quan trọng  như câu trả lời. Một số câu hỏi được pha trộn giữa kỹ thuật và lý thuyết, hoặc câu hỏi tìm hiểu quan điểm của ứng viên để tạo ra những câu hỏi khó khăn hơn. Các câu hỏi cũng thường được chia thành các thể loại khác nhau, một số câu hỏi mẹo sẽ được chèn vào giữa. Mục đích của những câu hỏi dạng đánh đố này là tìm kiếm những điểm yếu kỹ thuật thường chỉ xuất hiện khi ứng viên đi vào làm việc :| . Nhóm câu hỏi chung 1. Giữa các dự án mã mở và mã đóng, bên nào bảo mật hơn? Câu trả lời của ứng viên sẽ nói rất nhiều về họ. Nó cho thấy 1) họ biết những khái niệm gì trong phát triển phần mềm, 2) cho thấy mức độ chín chắn của ứng viên. Mục tiêu chính của câu hỏi là đưa ra được ưu/ nhược điểm của hệ mã đóng và mã m

Mã hóa đối xứng và bất đối xứng

Hôm nay mình xin được nói về hai thuật toán cơ bản và quan trong nhất trong bảo mật đó là mã hóa đối xứng và mã hóa bất đối xứng . 1. Mã hóa đối xứng (mã hóa không công khai- symmetric-key algorithms ) - Là lớp thuật toán các mã hóa trong đó việc mã hóa và giải mã đều dùng chung cho 1 khóa (secret key) 1.1 Các loại thuật toán khóa đối xứng Thuật toán đối xứng có thể được chia ra làm hai thể loại, mật mã luồng ( stream ciphers ) và mật mã khối ( block ciphers ). Mật mã luồng mã hóa từng bit của thông điệp trong khi mật mã khối gộp một số bit lại và mật mã hóa chúng như một đơn vị. Cỡ khối được dùng thường là các khối 64 bit. Thuật toán tiêu chuẩn mã hóa tân tiến ( Advanced Encryption Standard ), được NIST công nhận tháng 12 năm 2001, sử dụng các khối gồm 128 bit. Các thuật toán đối xứng thường không được sử dụng độc lập. Trong thiết kế của các hệ thống mật mã hiện đại, cả hai thuật toán bất đối xứng ( asymmetric ) (dùng chìa khóa công khai) và thuật toán đối xứng được sử