Phân tích hoạt động của giao thức HTTPS


Để hiểu rõ hơn hoạt động của giao thức HTTPS được mô tả trong bài viết này, bạn nên có sẵn kiến thức cơ bản về một số khái niệm liên quan sau:

  • Symmetric Encryption (hay Secret Key Encryption) và Asymmetric Encryption (hay Public-key Cryptography).
  • Các chức năng của SSL Certificate (một loại digital certificate) cũng như là các thông tin được chứa trong nó.
  • Vai trò của Central Authority (CA).

I. Giới thiệu

Giao thức HTTPS sử dụng port 443, giúp đảm bảo các tính chất sau của thông tin:

  • Confidentiality: sử dụng phương thức encryption để đảm bảo rằng các thông điệp được trao đổi giữa client và server không bị kẻ thứ ba đọc được.
  • Integrity: sử dụng phương thức hashing để cả client và server đều có thể tin tưởng rằng thông điệp mà chúng nhận được có không bị mất mát hay chỉnh sửa.
  • Authenticity: sử dụng digital certificate để giúp client có thể tin tưởng rằng server/website mà họ đang truy cập thực sự là server/website mà họ mong muốn vào, chứ không phải bị giả mạo.

Liên quan tới vấn đề này tôi có từng viết một bài về Desktop Phishing. Việc nhờ đến bên thứ 3 (thường là CA) để xác thực danh tính của website cộng thêm sự chú ý của người dùng rằng website đó có sử dụng HTTPS và SSL certificate của nó còn hiệu lực sẽ giúp loại bỏ hoàn toàn nguy cơ bị desktop phishing.

II. Sử dụng HTTPS như thế nào?

Trước hết, muốn áp dụng HTTPS thì trong quá trình cấu hình Webserver, bạn có thể dễ dàng tự tạo ra một SSL certificate dành riêng cho website của mình và nó được gọi là self-signed SSL certificate.

SSL certificate tự cấp này vẫn mang lại tính Confidentiality và Integrity cho quá trình truyền thông giữa server và client. Nhưng rõ ràng là không đạt được tính Authenticity bởi vì không có bên thứ 3 đáng tin cậy nào đứng ra kiểm chứng sự tính xác thực của certificate tự gán này. Điều này cũng giống như việc một người tự làm chứng minh nhân dân (CMND) cho mình rồi tự họ ký tên, đóng dấu luôn vậy!

Vì vậy, đối với các website quan trọng như E-Commerce, Online Payment, Web Mail,… thì họ sẽ mua một SSL certificate từ một Trusted Root CA nào đó như VeriSign, Comodo, GoDaddy,… Ở đây, các CA có  nhiệm vụ chính là cấp phát và quản lý các certificate.

Thực chất thì SSL certificate cũng là một loại digitial certificate (một loại file trên máy tính). Vì HTTPS có dính tới giao thức SSL nên người ta mới đặt tên cho nó là SSL certificate để phân biệt với các loại digital certificate khác như Personal Certificate, Server Certificate, Software Publisher Certificate, Certificate Authority Certificate.

Dưới đây là một số thông tin quan trọng được chứa trong SSL certificate:

  • Thông tin về chủ sở hữu của certificate (có thể là tổ chức, tên cá nhân hoặc tên miền của website).
  • Thông tin và digital signature của CA mà cấp certificate này.
  • Khoảng thời gian mà certificate còn hiệu lực.
  • Public key của website. Còn private key không có trong certificate mà được lưu trữ trên chính server và tuyệt đối không được để lộ cho bất cứ client nào.
  • Một số thông tin phụ khác như: loại SSL certificate, các thuật toán dùng để encryption và hashing, chiều dài (tính bằng bit) của key, cơ chế trao đổi key (như RSA, DSA).
  • v.v…

III. Quá trình giao tiếp giữa client và server thông qua HTTPS

1. Client gửi request cho một secure page (có URL bắt đầu với https://)

2. Server gửi lại cho client certificate của nó.

3. Client (web browser) tiến hành xác thực certificate này bằng cách kiểm tra (verify) tính hợp lệ của chữ ký số của CA được kèm theo certificate.

Giả sử certificate đã được xác thực và còn hạn sử dụng hoặc client vẫn cố tình truy cập mặc dù Web browser đã cảnh báo rằng không thể tin cậy được certificate này (do là dạng self-signed SSL certificate hoặc certificate hết hiệu lực, thông tin trong certificate không đúng) thì mới xảy ra bước 4 sau.

4. Client tự tạo ra ngẫu nhiên một symmetric encryption key (hay session key), rồi sử dụng public key (lấy trong certificate) để mã hóa session key này và gửi về cho server.

5. Server sử dụng private key (tương ứng với public key trong certificate ở trên) để giải mã ra session key ở trên.

6. Sau đó, cả server và client đều sử dụng session key đó để mã hóa/giải mã các thông điệp trong suốt phiên truyền thông.

Và tất nhiên, các session key sẽ được tạo ra ngẫu nhiên và khác nhau trong mỗi phiên làm việc với server. Ngoài encryption thì cơ chế hashing sẽ được sử dụng để đảm bảo tính Integrity cho các thông điệp được trao đổi.

IV. Tổng kết

HTTPS là một giao thức phổ biến trên Internet và rất cần thiết để đảm bảo an toàn, tin cậy cho môi trường Web. Tuy nhiên, vẫn có những cách thức mà attacker có thể sử dụng để “qua mặt” cơ chế bảo vệ của HTTPS (như SSLStrip).

Để kết thúc bài viết và cũng để các khái niệm liên quan tới HTTPS trở nên gần gũi và dễ hiểu hơn với mọi người, dưới đây là một tình huống thực tế:

CMND của người A do Công an ở địa phương B cấp. Người A này muốn thực hiện một giao dịch gì đó rất quan trọng với tổ chức C chẳng hạn. Và giả sử CMND của A là thứ duy nhất mà C có thể dựa vào để tin tưởng được các thông tin về A như khuôn mặt, tên, tuổi, nơi ở… Vì C thấy CMND cũng có thể bị làm giả và để chắc rằng các thông tin về A được ghi trong CMND là chính xác thì cách tốt nhất là C đem CMND của A đến nhờ bên B xác thực giùm.

Như vậy, có thể coi:

  • Bên A là website
  • Bên B là CA
  • CMND của A chính là SSL Certificate do B cấp
  • Bên C là Web client
–manthang

14 comments

  1. Lý thuyết cơ bản đã rất vững.
    Anh chỉ gợi ý thêm. Nếu một cuộc tấn công man-in-middle xảy ra kể từ thời điểm bắt đầu giao dịch, lúc client gửi HTTPS request đến SERVER thì có khả năng xảy ra là attacker có thể lấy được key và làm lộ toàn bộ phiên làm việc HTTPS này không ?
    :D

    1. Bữa giờ em chưa đào sâu về attack HTTPS connection bằng MiTM nên giờ mới reply cho anh được :D
      Theo em thì với MiTM, attacker chỉ có thể lấy được key mà ai cũng có thể lấy là public key. Còn muốn có private key thì attacker phải bằng cách khác để xâm nhập vào CA hoặc server.
      Việc HTTPS session bị lộ là do attacker tạo symmetric key và thay mặt cho client truyền nhận encrypted traffic với server rồi chuyển về dạng uncrypted traffic trước khi gửi lại cho client. (vụ này anh Xnohat nắm rõ hơn em nhiều, em sẽ tìm hiểu kỹ lại rồi lại ‘chém’ tiếp cùng anh :p).

  2. Chào bạn, mình đang tìm hiểu về cài SSL cho trang web ở máy local. MÌnh đã xin chứng chỉ số SSL của verysign để test thử.
    Trong vmware mình thử cài Cain & Abel để sniff pass thử thì ở giao thức http mình thấy được pass, nhưng ở giao thức https thì Cain & Abel không thấy được.
    Theo suy nghĩ của mình thì dùng Cain có thể thấy được pass ở dạng bị mã hóa nhưng tại sao nó không sniff được với giao thức https?
    Vậy có cách nào để phân biệt rõ ràng sự khác nhau giữa http và https trong bảo mật không, tool nào có thể thấy được rõ nhất.

    1. Muốn giải mã thông điệp thì:
      – phải coi thuật toán/cơ chế mã hóa được sử dụng có vững mạnh hay không?
      – nếu thuật toán/cơ chế mã hóa ok rồi thì xét xem key được sử dụng có phức tạp/khó đoán hay không?
      – key tốt rồi thì cũng cần quan tâm tới biện pháp lưu trữ/bảo mật key có tốt hay không?

      AES, RSA là 2 thuật toán mã hóa mạnh thường được sử dụng trong HTTPS.
      ở đây, muốn giải mã thông tin được HTTPS bảo vệ thì bạn (hay chương trình Cain & Abel) cần biết được symmetric key (hay còn gọi là session key) được mã hóa bởi public key => bạn phải có được private key.

      Còn về câu hỏi:
      “Vậy có cách nào để phân biệt rõ ràng sự khác nhau giữa http và https trong bảo mật không, tool nào có thể thấy được rõ nhất.”

      thì 1 cách đơn giản hơn để nhận biết là gói tin HTTP thường được gửi tới port 80 của server, còn HTTPS là port 443.
      vì listening port có thể được đổi trên server nên bạn cần dùng các tool packet anlyzer như Wireshark để biết được chính xác protocol nào được sử dụng tại tầng Application.

    1. “Web thường” như bạn nói thì mình hiểu đó là các website:
      – chỉ đăng lên các các thông tin giới thiệu về công ty/tổ chức, trưng bày sản phẩm/dịch vụ, quảng cáo…
      – forum, blog cá nhân
      – giải trí, tin tức,…
      v.v.. nói chung là các website không có dính dáng tới giao dịch thương mại, tiền bạc hay cần bảo mật tài khoản người dùng thì theo mình không cần tốn phí để triển khai HTTPS (mua SSL certificate) làm gì.

      HTTPS giúp đảm bảo tính xác thực của website và đồng thời mã hóa thông tin truyền giữa client-server nhưng nó không phải là chìa khóa vạn năng. Để website tránh bị deface, ddos, fake… thì còn cần quan tâm tới nhiều chuyện khác nữa.

      bạn coi thêm thảo luận này:
      http://www.hvaonline.net/hvaonline/posts/list/40716.hva

  3. Cảm ơn bài viết của anh!
    Em có vài chỗ còn mơ hồ về vai trò của CA. Mong anh giải đáp

    Certificate của server gửi lại cho client có chữ ký. Theo em nghĩ chữ ký này là do server dùng private key để ký, có đúng không anh? Vậy các CA làm cách nào để chứng mình là cái public key đó là do chính server gửi cho client?

    Giả sử em sử dụng MiTM, làm giả cert của server, e làm giả tất cả thông tin của cert, thay cả public key và ký bằng private key của em, thì làm sao client biết được cert này là đồ giả? Trừ khi client yêu cầu kiểm tra lên CA thì mới phát hiện được, thế thì gửi cái gì để mà kiểm tra hả anh?

    Em có thử thực hiện một demo dùng Cain để làm giả cert, bên phía chỉ hiện một cảnh báo là “Chứng thư không được tin cậy vì không có chuỗi nhà cấp phát nào.” Không lẽ việc làm giả có chỗ không làm giả được?

    Hi vọng anh có thể dành chút thời gian trả lời cho em.. :D

    1. theo mình thi cái chữ ký ở trong cert của server gửi cho client này là của VA (bên thứ 3 tin cậy). tất nhiên bên client có khóa công khai của bên CA này có thể chứng minh dc chữ ký đó là của ai ký rồi. nếu mà là của CA và và cái cert này vẫn còn hiệu lực thì cái khóa công khai của bên server sẽ dc client sử dụng để mã hóa một thông điệp và gửi cho server. vấn đề là bên thứ 3 tin cậy!
      ý thứ 2 là giả mạo: thì cái chữ ký trên cert này ko dc ký bởi server mà dc ký bởi CA. và cái khóa công khai kia là của server chứ ko phải của CA nên dùng khóa đó ko xác thực dc sign của CA. do đó bị phát hiện!

      ko biết mình nói như thế có chuẩn không Manthang

      1. Cảm ơn anh. Câu hỏi này em hỏi cũng lâu lắm rồi, và cũng có câu trả lời giống như anh. Em cũng bổ sung thêm ý 2.

        Thực ra, cert mà attacker gửi cho victim là cert tự ký, nhưng cert này không có chuỗi “nhà cấp phát tin cậy”, vì nếu có victim sẽ dùng key public của CA mà kiểm tra cert có bị thay đổi nội dung hay không —> sẽ phát hiện được cert giả mạo này.

        Mặt khác, bên victim sẽ hiện cảnh báo nhưng vẫn có thể chấp nhận cert này tùy thuộc vào cách xử lý của victim.

  4. 3. Client (web browser) tiến hành xác thực certificate này bằng cách kiểm tra (verify) tính hợp lệ của chữ ký số của CA được kèm theo certificate. –> Xin giải thích rõ hơn cho mình phần này. Client sẽ verify bằng cách nào.

    Thanks!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s