Zero Trust Supply Chain, DevSecOps and Cloud [part 2]

Ở phần 1 (https://blog.thecoe.cloud/2022/04/18/zero-trust-supply-chain-devsecops-and-cloud-part1/), tôi đã đề cập đến những khái niệm chung về PKI, tiếp theo chúng ta hãy cùng nhau xem một cert thực tế nó sẽ chứa nội dung gì. Tôi sẽ lấy website của báo chungta.vn của FPT làm ví dụ. Đây là cert của báo chungta.vn khi các bạn kiểm tra trên web browser.

Tuy nhiên là vì cert quá dài nên tôi dùng 1 tool khác để inspect cert này trong terminal và chụp màn hình dưới đây.

Chúng ta hãy đi từng nội dung chính trong screenshot trên nhé:

Version: 3 – Version 3 của X509 chính là format của cert này.

Issuer: Nơi cấp certificate này hay còn gọi là CA – Certification Authority. Ở đây, cert của chungta.vn được cấp bởi DigiCert.

Subject: Thông tin về chủ thể. Trong cert này thể hiện rằng, domain .chungta.vn thuộc về tập đoàn FPT, địa chỉ bla bia.

Subject Public Key Info: Đây chính là thông tin về public key của subject bên trên. Như tôi có đề cập phía trên thì 2 nội dung chính mà 1 cert cần phải chứa đó là tên/định danh của chủ thể và public key của chủ thể.

Hay để ý một chút đến phần X509v3 extensions:

X509v3 Subject Alternative Name: Đây chính là domain name mà public key được “gán” vào. Nó cũng được nhắc đến trong phần subject phía trên.

X509v3 Basic Constraints: critical

     CA:FALSE

CA:FALSE thể hiện rằng, đây không phải là cert của một CA, nó là cert của một domain name thông thường (ở đây là chungta.vn).

Signature: Đây chính là chữ ký mà CA ký để chứng thực rằng: domain chungta.vn không phải là một domain fake, đây là domain an toàn, được Issuer xác nhận, các bạn user có thể yên tâm truy cập.

Vậy một câu hỏi đặt ra là: Thế tại sao mỗi lần tôi truy cập vào chungta.vn trên web browser (tôi hay dùng google chrome), thì web browser lại chứng thực được cái certificate kia? Theo lý thuyết thì cert của chungta.vn được ký bởi một bên đơn vị uy tín, mà như đề cập phía trên thì để chứng thực chữ ký cần phải có public key. Điều này chứng tỏ bằng một cách nào đó, Chrome đang chạy trên laptop của tôi “biết” được public key của đơn vị uy tín kia? (Lưu ý rằng, Chrome trong ví dụ này có thể được coi là 1 relying party trong PKI, các bạn có thể gặp cụm từ RELYING PARTY này khá nhiều trên Internet khi nói về PKI, tuy nhiên tôi sẽ không đi làm rõ nó để tránh dài dòng, các bạn có thể tự tìm hiểu nó.)

Đơn giản là vì Chrome đang chạy trên laptop của tôi đã được “cấu hình” với một danh sách các TRUSTED ROOT CERTIFICATES và danh sách này được gọi với cái tên TRUSTSTORE. Tôi không muốn dùng từ “cấu hình” lắm bởi vì thực chất là Chrome chỉ sử dụng cái TRUSTSTORE nằm sẵn trong MacOS (tôi dùng Mac nhé các bạn :d, cám ơn FPT đã tài trợ cho tôi con Mac để tôi có thể ngồi đây viết những dòng này :D). TRUSTSTORE hay cách thức mà một web browser truy cập TRUSTSTORE nó khác nhau phụ thuộc vào web browser (FireFox, Internet Explorer, etc. ) cũng như các thiết bị hay hệ điều hành mà các bạn dùng. Tôi dùng Mac và Chrome do đó tôi sẽ show cho các bạn cái TRUSTSTORE này như thế nào, tuy nhiên trước tiên chúng ta cần phải hiểu ROOT CERTIFICATE và tại sao có ROOT CERTIFICATE thì Chrome lại chứng thực được cái signature như đề cập bên trên?

ROOT CERTIFICATE?
Chúng ta phải một lần nữa đồng ý với nhau rằng ROOT CERTIFICATE là một CERTIFICATE, tức là nó mang đầy đủ tính chất của một CERTIFICATE. Nó phải chứa thông tin về Public Key và chủ thể mà nó hướng đến. Chỉ có 1 điều khác biệt với cert của chungta.vn đó là nơi cấp cert (issuer) và chủ thể (subject) mà nó hướng đến LÀ 1, hay ta còn gọi là SELF-SIGNED CERTIFICATE (nôm na là cert tự ký). Tức là đơn vị uy tín cung cấp cert mà tôi hay nhắc ở trên tự ký một cái cert mà trong đó có lưu cái public key của đơn vị đó. Cert này chính là ROOT CERTIFICATE.

Đến đây, bài toán đã rõ, Chrome sau khi nhận được cert của chungta.vn (quy trình HTTPS hoạt động như thế nào để nhận cert các bạn tự tìm hiểu nhé) sẽ truy cập vào TRUSTSTORE trên máy Mac của tôi, kiểm tra xem trong TRUSTSTORE có ROOT CERTIFICATE của đơn vị cấp cert hay không (là DigiCert trong ví dụ này). Nếu có, public key của ROOT CERTIFICATE sẽ được lấy ra để verify cái cert của chungta.vn. Tôi sẽ show cho các bạn TRUSTSTORE trong máy Mac của tôi có chứa thông tin về ROOT CERTIFICATE của DigiCert không nhé.

Một điều khá thú vị ở đây là ROOT CERTIFICATE chính là một dạng SELF-SIGNED CERTIFICATE (tôi gọi dân dã là cert tự ký). Đã là cert tự ký thì ai cũng có thể tự ký được. Nôm na là bạn tự ký một cái cert và lấy cái cert đó chứng minh rằng: chính là tôi chứ không phải ai khác, hãy tin tôi đi. Quay trở lại ví dụ trên thì DigiCert cũng tự ký một cái cert để chứng minh rằng: Tôi chính là DigiCert, tôi rất uy tín và tin cậy, hãy tin và sử dụng tôi để làm Issuer. Nhưng nếu ai cũng có thể tự ký được thì người dùng biết tin ai bây giờ? Đơn giản là xã hội loài người vận hành một phần nào đó dựa trên lòng tin các bạn ạ (TRUSTWORTHY). Tất nhiên chúng ta cũng cần phải xem ai đứng sau tổ chức DigiCert này, ai vận hành nó, nó có giấy phép hoạt động như thế nào, etc. Suy cho cùng ta cũng cần một cái gì đó để tin vào, làm cơ sở cho mọi hoạt động.

Đến đây, hi vọng các bạn cũng đã có hình dung nào đó về cách thức một PKI hoạt động với cert và ví dụ về báo chungta.vn mà tôi vừa nói chính là một hình dung thực tiễn cho Web PKI. Sẽ có một hình thái khác của PKI, nơi đó CODE SIGNING vô cùng quan trọng, đó chính là Internal PKI, tôi sẽ nhắc đến ở phần sau.

Tiếp theo, tôi muốn đề cập đến 1 vấn đề khá thú vị về PKI, tôi nghĩ một số bạn cũng biết hoặc cũng có để ý đến nó, đó chính là về format của các cert. Có rất nhiều format của các cert như X509, PEM, PKCS, etc. quá là nhiều, nhưng trong đó x509 là format phổ biến và thông dụng nhất. Các bạn có để ý trong cert của chungta.vn, ta thấy cả một đoạn dài ghi rõ tên, tuổi, địa chỉ tỉnh thành, đất nước, etc. trong khi nội dung chính chỉ là chứng thực cái domain chungta.vn? Hoặc những ai đơn giản là từng dùng OpenSSL để tạo các public/private key theo x509 thì thấy rằng x509 yêu cầu chúng ta phải điền khá nhiều nội dung liên quan đến tỉnh thành, đất nước, tổ chức mà xét về mặt logic thì không liên quan lắm. Tất cả đều có lịch sử của nó.

X509 chính là phiên bản mở rộng, cải tiến của X500 – một dự án nhận được sự bảo trợ của  ITU-T (ITU Telecommunication Standardization Sector), gọi tắt là liên minh viễn thông quốc tế. Họ tạo ra dự án X500 với mong muốn tạo ra một danh bạ điện thoại toàn cầu. Mà danh bạ điện thoại toàn cầu thì đương nhiên phải có thông tin của quốc gia, tỉnh thành, etc. Dự án này không thành công nhưng di sản của nó để lại chính là X509. Nói cho đúng thì X509 khởi nguồn không phải là để cho Web PKI, mà nó được thiết kế tầm 30 năm trước cho danh bạ điện thoại.

Ok, tôi xin dừng phần 2 ở đây, hi vọng các bạn có những thông tin thú vị. Phần 3 sẽ là phần quan trọng nhất của series này khi tôi sẽ trao đổi về Internal PKI cũng một giải pháp mã nguồn mở cho PKI được sử dụng trong DevSecOps, một lá chắn hữu hiệu cho Supply Chain Attack theo tư duy Zero Trust. Và đương nhiên, tôi cũng sẽ setup một demo nho nhỏ để mô phỏng ý tưởng này.

Hẹn gặp lại ở phần 3 !!!!

Vietstack/Tuti

1
0

Leave a Reply

Your email address will not be published. Required fields are marked *