Xin chào các bạn, trong bài viết này mình muốn chia sẻ về một kĩ thuật rất nên dùng khi cần tăng tính bảo mật của kết nối internet: SSL Pinning
Trong bài viết trước, mình đã giải thích khá kĩ về SSL, nên trong bài viết này mình mặc định các bạn đã hiểu về SSL và không nhắc lại khái niệm nữa nha.
Nếu bạn đang đọc bài này và còn mơ hồ về SSL, mình khuyến khích các bạn đọc bài viết trước của mình đã nhé.
Bypass SSL như thế nào?
Ở cuối bài viết trước, mình có nói rằng hacker có thể bypass SSL. Vậy cụ thể là làm thế nào để bypass?
Như chúng ta biết mục đích của SSL là để đảm bảo chúng ta truyền dữ liệu đến đúng nơi mình muốn, và chỉ 1 trong 2 bên mới có thể giải mã dữ liệu này. Bằng cách sử dụng SSL certificate, chúng ta có thể chắc chắn được phần nào rằng nơi mà chúng ta đang truyền dữ liệu tới là một nơi được tin tưởng.
Tuy nhiên, hacker hoàn toàn có thể sử dụng thao tác đơn giản để khiến cho client hoàn toàn tin tưởng certificate của mình. Để hiểu được phần này đầu tiên chúng ta cần hiểu rõ hơn cơ chế hoạt động của SSL Certificate, và cách mà client quyết định xem có tin tưởng một certificate hay không.
Cơ chế hoạt động của SSL Certificate
SSL Certificate của google.com
Như trong bài viết trước mình đề cập, khi bắt đầu handshake server sẽ phải gửi một certificate về phía client. Certificate này giống như một chiếc chứng minh thư, chứa đựng thông tin danh tính của server.
Chiếc certificate này sẽ chứa cả thông tin của bên phát hành. Như trong hình trên bạn có thể thấy thông tin của bên phát hành ở mục Issuer Name.
Bên phát hành này có thể là một tổ chức được nhiều bên tin tưởng và công nhận, gọi là Certificate Authority (CA), hoặc là một bên ất ơ nào đấy không ai thèm tin (loại certificate ất ơ này gọi là self-signed certificate).
Bạn có thể tưởng tượng 2 loại certificate này giống như 2 loại bằng lái máy bay vậy. Loại đầu tiên do Cục hàng không Quốc gia cấp, loại thứ 2 là loại làm bằng photoshop, sai chính tả tùm la tùm lum. Giả sử bạn là hành khách trên một chuyến bay, bạn sẽ muốn phi công có loại bằng lái nào hơn? Tất nhiên là loại 1 rồi!
Quá trình để có được 1 certificate loại 1 có thể đơn giản hoá như sau:
- Bên A tạo ra một certificate request có chứa thông tin danh tính của bên A
- Bên A gửi certificate request này cho CA để xác nhận
- Sau khi CA kiểm tra và thấy ok thì sẽ phát hành 1 certificate cho bên A và kí xác nhận vào certificate này. Các bên CA này sẽ thu tiền để cấp certificate cho bạn nha. Giá rổ khác nhau thì độ bao phủ (được bao nhiêu system tin tưởng) cũng khác nhau.
Còn đối với certificate loại 2, ông A tự kí xác nhận certificate đấy luôn, từ đó sinh ra cái tên self-signed (tự kí).
Do đó, các certificate được phát hành bởi Certificate Authority thường đã được các system tin tưởng rồi. System ở đây có thể là iOS, macOS… và những cái tương tự. Ứng dụng của bạn tất nhiên sẽ chạy trên một trong những system này. Nếu các bạn dùng macOS, các bạn có thể mở ngay Keychain Access để thấy một list các CA được system tin tưởng. Ví dụ như trên máy mình:
Thông thường các ứng dụng chạy trên system sẽ hoàn toàn ủy quyền cho system để xác nhận xem certificate của server có tin được hay không. Chẳng hạn một ứng dụng trên iPhone sẽ ủy quyền cho iOS.
iOS tất nhiên cũng sẽ có một nơi để chứa tất cả các CA mà iOS tin tưởng, gọi là Trust Store. Khi nhận được certificate từ server thì iOS sẽ xác định xem bên phát hành certificate đó có mặt trong Trust Store hay không, nếu có thì mới chơi với nhau tiếp.
Phương pháp này có một điểm yếu, đấy là hacker có thể tự cài đặt self-signed certificate của mình vào trong Trust Store. Cách cài đặt lại cũng rất đơn giản, bấm bấm mấy cái là được, mình sẽ không đi vào chi tiết để tránh lan man.
Như vậy nếu chỉ dựa vào system để xác định có tin tưởng một server hay không là không đủ.
Đây chính là lí do cần phải có SSL Pinning.
Vậy SSL Pinning là gì?
(Pin cái gì cơ? Pin con thỏ á?)
Nói thật với các bạn, trong một khoảng thời gian rất lâu mình cứ bị nhầm giữa từ pinning (ghim) và spinning (xoay), nên mình cứ nghĩ SSL pinning là xoay vòng tròn như nào đấy ghê gớm lắm =)).
Nhưng thực ra không phải. Pinning ở đây nghĩa là ghim. Ghim là ghim 1 cái server với một cái certificate hoặc public key, kiểu như server này chỉ đi với certificate này, hoặc public key này thôi.
Nghe vẫn hơi mơ hồ nhỉ, để mình giải thích rõ hơn:
Certificate của một server là công khai, bất kì ai cũng có thể lấy được certificate này. Nếu không biết dùng câu lệnh thì dùng Chrome cũng đủ để lấy rồi. Lấy như này này:
- Khi vào một trang HTTPS các bạn sẽ thấy có cái hình ổ khóa ở trên thanh address bar. Bấm vào đấy, rồi bấm tiếp vào Certificate.
- Sẽ hiện lên cái này:
Bạn sẽ thấy certificate của server xuất hiện. Ở Windows thì các bạn bấm vào Details là có nút download, còn trên macOS thì bạn kéo cái thumbnail của certificate ra Desktop là được.
Tại sao trong hình trên lại có đến 3 certficiate? Cái này tùy thuộc vào bên CA.
- Cái certificate trên cùng sẽ là root certificate, chính là certificate chứa thông tin của bên CA đấy.
- Cái cuối cùng chính là certificate được bên CA phát hành cho server google.com. Public key dùng để mã hóa data sẽ là lấy từ certificate này.
- Cái ở giữa thì để làm trung gian, trung gian cho cái gì thì mình chịu =)), chắc là nghiệp vụ của bên CA, mình quá lười tìm hiểu. Bạn nào hiểu rồi thì comment giải thích cho mình với
.
System chỉ cần trust root certificate là sẽ tiến hành handshake với server (ở đây là google.com) được rồi, mặc kệ cái certificate dưới cùng có đúng là certificate của google.com hay không.
Vậy phía client cần một cách để đảm bảo dù đã root certificate đã được trust, nhưng cái certificate dưới cùng không phải là của google.com thì sẽ không tiến hành kết nối. Đây chính là mục đích của SSL pinning.
Cách thực hiện SSL Pinning
Để thực hiện SSL pinning có nhiều cách, nhưng phổ biến nhất là 2 cách sau:
- Pin cả cái certificate: Bạn để luôn cái server certicate ở phía client. Khi handshake mà nhận được certificate từ server thì so sánh xem cái nhận được với cái mình đã lưu có giống nhau không. Nếu giống thì mới kết nối.
- Pin riêng cái public key: Phía client lấy certificate chuẩn của server về, tách cái public key ra, rồi lưu lại. Khi handshake thì xem public key trong certificate nhận được có giống với cái mình đã lưu không.
Tác dụng của SSL Pinning
Vậy việc pinning này có tác dụng gì?
Nếu hacker muốn giả mạo làm server, thì hacker vẫn phải trả về cho bạn một chiếc certificate để tiến hành handshake.
Certificate này không thể là certificate của server google.com như trong ảnh trên được, vì như trong bài viết trước mình đã đề cập, mỗi certificate đều chứa public key dùng để mã hóa data, và chỉ bên có private key mới giải mã data được (mà hacker thì lấy đâu ra private key của google chứ).
Do đó, để giải mã được data hacker cần phải trả về cho bạn cái certificate mà chính hắn tạo ra. Certificate đểu này mà được system tin tưởng rồi thì ứng dụng của bạn toang.
Do đó, bạn cần lưu cái certificate (hoặc public key) chuẩn của server google.com ở phía app, rồi khi nhận được certificate từ server trong quá trình handshake thì bạn sẽ so sánh 2 cái certificate với nhau, nếu khác nhau thì á à thằng lừa đảo đây rồi =))).
Bạn có thể liên tưởng kiểu này:
- Để xác định xem chứng minh thư mà bạn nhận được có đúng là của ông A hay không, thì bạn có thể kiểm tra phần dấu vân tay.
- Do bạn đã lưu dữ liệu dấu vân tay của ông A từ trước đó rồi, nên bạn có thể so sánh dữ liệu của bạn và dữ liệu trên chiếc chứng minh thư bạn nhận được. Nếu khác nhau một chút thôi là nghỉ chơi luôn.
Bằng việc so sánh như vậy, chúng ta hoàn toàn có thể ngăn chặn việc hacker cài đặt root certificate để bypass SSL rồi!
Nên chọn certificate pinning hay public key pinning?
Hi vọng đến đây bạn đã hiểu được bản chất của SSL pinning rồi.
Phần này là ngoài lề một chút. Mình không muốn đi quá sâu vào phần kĩ thuật, nhưng vẫn muốn giúp các bạn phân biệt certificate pinning và public key pinning, vì mình nghĩ việc này sẽ có ích với các bạn đang muốn implement SSL pinning cho ứng dụng của mình. Sự khác nhau giữa 2 loại pinning này như sau:
- Pin certificate: Dễ hơn. Bạn so sánh cái certificate lưu ở app với cái certificate nhận được từ server là được.
- Pin public key: Linh hoạt hơn, nhưng khó hơn một chút. Bạn phải tách được public key từ certificate của server ra rồi so sánh với public key đang lưu ở client.
Pin public key thì linh hoạt hơn như thế nào?
Giả sử certificate của server bị hết hạn, hoặc vì lí do trời ơi đất hơi nào đấy mà bạn cần tạo ra một cái certificate khác cho server.
- Nếu bạn dùng certificate pinning, bạn sẽ phải update phía client để thay certificate cũ đang lưu ở client bằng certificate mới
- Nếu bạn dùng public key pinning thì không cần, vì bạn hoàn toàn có thể tạo ra một certificate mới có public key giống cái cũ
Như vậy, nếu server của bạn cần thay đổi certificate thường xuyên, thì lựa chọn public key pinning sẽ hợp lý hơn. Trường hợp duy nhất bạn cần phải update public key ở phía client mà mình có thể nghĩ tới là khi bạn muốn thay cả cái private key ở server (kiểu dùng lâu quá rồi sợ bị lộ ấy).
Đến đây có thể bạn sẽ hỏi, nếu public key là public, ai cũng có thể lấy được, thì chẳng nhẽ hacker không thể chèn cái public key đấy vào certificate đểu của bọn nó hay sao? Theo mình biết thì không làm được kiểu đấy, vì khi tạo ra certificate thì cần có cả private key. Mà public key và private key thì là 1 cặp đi đôi với nhau.
Nhưng đấy là vì mình không phải hắc cơ xịn, chứ hắc cơ pro thì chắc vẫn làm được. Nhưng kể cả là có làm được, và phía client chấp nhận kết nối rồi, thì hacker cũng có private key để mà giải mã data đâu? 
Bài viết của mình đến đây là kết thúc. Hi vọng qua bài viết này các bạn đã có cái nhìn sâu hơn về kết hơn internet, và hiểu được bản chất kĩ thuật SSL pinning.
Nếu các bạn thấy bài viết của mình dễ hiểu, mời các bạn follow mình để đọc các bài viết tiếp theo nha. Sắp tới mình dự định làm một series giải thích cụ thể về Design patterns, trong đó không chỉ tập trung vào HOW mà quan trọng hơn cả là WHY - Tại sao dùng design pattern lại giúp bạn tiết kiệm thời gian và bớt đau đầu hơn trong công việc lập trình.
Mời các bạn đón đọc nha hehe.