Làm cách nào để Kiểm tra CRL và OSCP hoạt động trên iOS?

Tôi không thể để CRL hoạt động trên iOS. Tôi đã tạo ra hai trường hợp thử nghiệm. Tôi có một chứng chỉ hợp lệ, do CA. Tôi có một chứng chỉ khác hợp lệ, do CA cấp, nhưng CA đã thêm chứng chỉ đó vào CRL của nó.

Sau đó, tôi thiết lập chính sách thu hồi cho phép kiểm tra CRL và yêu cầu nó thành công.

func crlValidationTest(trustedCert: SecCertificate, certToVerify: SecCertificate) -> Bool {

    let basicPolicy = SecPolicyCreateBasicX509()

    let crlPolicy = SecPolicyCreateRevocation(kSecRevocationOCSPMethod | kSecRevocationCRLMethod | kSecRevocationRequirePositiveResponse)!

    var trust: SecTrust?

    SecTrustCreateWithCertificates(NSArray(object: certToVerify), NSArray(objects: basicPolicy, crlPolicy), &trust)
    SecTrustSetAnchorCertificates(trust!, NSArray(object: trustedCert))
    SecTrustSetNetworkFetchAllowed(trust!, true)

    var trustResult = SecTrustResultType.invalid

    guard SecTrustEvaluate(trust!, &trustResult) == errSecSuccess else {
        return false
    }

    return trustResult == SecTrustResultType.proceed || trustResult == SecTrustResultType.unspecified
}

Kỳ vọng của tôi là chứng chỉ trên CRL sẽ không đáng tin cậy và chứng chỉ sạch sẽ được tin cậy.

Với cấu hình trên, cả hai đều thất bại như không đáng tin cậy. Nếu tôi gỡ kSecRevocationRequirePositiveResponsecờ, cả hai đều thành công. Tôi đã thử tất cả các hoán vị khác nhau khi chỉ sử dụng OSCP hoặc chỉ CRL và không có gì hoạt động theo cách tôi mong đợi.

Tài liệu Táo cho SecPolicyCreateRevocationcác tiểu bang:

Thông thường, không cần thiết phải tự tạo chính sách hủy bỏ trừ khi bạn muốn ghi đè hành vi hệ thống mặc định, ví dụ để buộc một phương thức cụ thể hoặc vô hiệu hóa kiểm tra hủy bỏ hoàn toàn.

Chỉ sử dụng SecPolicyCreateBasicX509chính sách cho phép cả hai thành công (khi chứng nhận thứ hai không thành công), vậy hành vi mặc định của Apple có phải là không kiểm tra CRL không?

Tôi đã gắn CharlesProxy vào thiết bị của mình và chạy mã nhiều lần trong khi lắng nghe tất cả lưu lượng truy cập mạng và không có yêu cầu gửi đi nào đến CRL, điều này giải thích tại sao tất cả đều thất bại khi RequirePositiveResponsekiểm tra cờ.

Tôi cũng đã thử điều hướng trực tiếp từ thiết bị đến CRL bằng cách sử dụng a URLRequestvà có thể lấy dữ liệu CRL trên thiết bị mà không gặp sự cố nào.

Kiểm tra CRL không được hỗ trợ qua thư viện Apple Security? Nếu có, có ai đã tìm ra cấu hình để khiến nó phản hồi chính xác chưa? Những lựa chọn thay thế nào được sử dụng để xác thực CRL, tôi cho rằng các ứng dụng di động có độ bảo mật cao giao dịch trong khu tài chính hoặc các khu vực nhạy cảm khác sẽ không cho phép khoảng cách bảo hiểm này.

CẬP NHẬT Để so sánh, tôi đã chạycertutil -f -urlfetch -verify MYCERT.cerbằng certutil và tôi đã gắn Fiddler vào hộp chạy lệnh. Tôi nhận được kết quả mong đợi mà iOS sẽ không cung cấp cho tôi và tôi thấy một yêu cầu gửi đến CRL thông qua HTTP thông qua fiddler.

Tôi đã tạo ra một tiền thưởng để tạo thêm một số quan tâm trong việc này. Tôi hy vọng ai đó có nhiều chi tiết hơn về những gì đang được thực hiện sai ở trên hoặc tại sao điều này không hoạt động trên iOS.

Trên các nền tảng của Apple, khách hàng không kiểm tra Danh sách thu hồi chứng chỉ (CRL) của CA, cũng như không sử dụng OCSP theo mặc định.

Tuy nhiên, các nền tảng của Apple đang hỗ trợ dập ghim OCSP và thay vào đó, họ cung cấp một cơ chế mà họ gọi là Tăng cường Thu hồi, thực sự có thể dẫn đến một cuộc gọi OCSP, xem chi tiết bên dưới.

Ghim OCSP

Đầu tiên là một giải thích về dập ghim OCSP:

Các Status Online Certificate Protocol (OCSP) kẹp , chính thức được gọi là Status Certificate Request TLS mở rộng, là một tiêu chuẩn để kiểm tra tình trạng thu hồi giấy chứng nhận X.509 kỹ thuật số. 1 Nó cho phép người trình bày chứng chỉ chịu chi phí tài nguyên liên quan đến việc cung cấp phản hồi Giao thức trạng thái chứng chỉ trực tuyến (OCSP) bằng cách nối thêm ("dập ghim") một phản hồi OCSP được đóng dấu thời gian được CA ký vào bắt tay TLS ban đầu, loại bỏ nhu cầu để khách hàng liên hệ với CA, với mục đích cải thiện cả bảo mật và hiệu suất.

xem https://en.wikipedia.org/wiki/OCSP_stapling

Sự khác nhau giữa ghim OCSP và OCSP

Nếu máy khách kết nối với máy chủ theo luồng OCSP truyền thống và truy xuất chứng chỉ, nó sẽ kiểm tra xem chứng chỉ nhận được có bị thu hồi hay không bằng cách gửi yêu cầu tới CA. Điều này có một số nhược điểm, ví dụ, cần có kết nối mạng bổ sung, thông tin không được mã hóa và do đó thể hiện vấn đề bảo mật dữ liệu.

Thông qua việc ghim OCSP, máy chủ yêu cầu thông tin thu hồi đã ký từ CA và thêm nó vào bắt tay TLS.

Điều này cũng có nghĩa là, khi sử dụng ghim OCSP, bạn không thấy yêu cầu OCSP từ iOS đến máy chủ CA.

Hạn chế của ghim OCSP

Máy chủ bạn đang kết nối phải hỗ trợ dập ghim OCSP. Điều này cũng không bảo vệ chống lại các máy chủ độc hại.

Đó là những lý do chính tại sao Apple cung cấp Cải tiến Thu hồi.

Cải tiến thu hồi của Apple

Đây là cách nó hoạt động:

• Các mục nhật ký trong suốt chứng chỉ được Apple thu thập
• với thông tin này, Apple thu thập thông tin về việc hủy bỏ từ các CA
• thông tin tổng hợp này sau đó sẽ tự động được cung cấp cho tất cả các khách hàng của Apple một cách thường xuyên
• dựa trên thông tin này, khi một ứng dụng iOS cố gắng kết nối với máy chủ bằng chứng chỉ bị thu hồi, nó sẽ thực hiện kiểm tra bổ sung qua OCSP.

Yêu cầu

Yêu cầu duy nhất cho một ứng dụng hỗ trợ này là chứng chỉ máy chủ được sử dụng được thêm vào nhật ký minh bạch chứng chỉ. Thông thường, CA đã thực hiện điều đó rồi, nhưng bạn nên kiểm tra xem chứng chỉ miền có trong nhật ký minh bạch hoạt động cho chứng chỉ công cộng hay không, ví dụ: bằng cách sử dụng liên kết sau: https : //trans minhreport.google.com/https/certert

WWDC 2017, phiên 701

Có một phiên WWDC tuyệt vời trong đó chủ đề này và động cơ của Apple được giải thích chi tiết: WWDC 2017, phiên 701: https://developer.apple.com/ideo/play/wwdc2017/701/

Khoảng phút 12:10, một kỹ sư của Apple giải thích chi tiết toàn bộ chủ đề thu hồi. Vào khoảng 15:30, cô giải thích rằng OCSP bình thường sẽ yêu cầu sử dụng các API bổ sung.

Kiểm tra ghim OCSP trên iOS

Để kiểm tra, chúng tôi cần một máy chủ hỗ trợ dập ghim OCSP và sử dụng chứng chỉ bị thu hồi: https://revoking.grc.com (tìm thấy máy chủ này trong câu trả lời của máy chủ này: https://serverfault.com/a/645066 )

Sau đó, chúng ta có thể thử kết nối từ iOS bằng một chương trình thử nghiệm nhỏ cố gắng tải xuống phản hồi HTML và xuất nó ra bàn điều khiển.

Dựa trên thông tin từ phiên WWDC được đề cập ở trên, nỗ lực kết nối sẽ thất bại.

...
let session = URLSession(configuration: .default)
...

func onDownloadAction() {
    let url = URL(string: "https://revoked.grc.com")!
    self.download(from: url) { (result, error) in
        if let result = result {
            print("result: " + result)
        } else {
            print("download failed")
            if let error = error {
                print("error: \(error)")
            }
        }
    }
}


func download(from url: URL, completion: @escaping(String?, Error?)->Void) {
    let dataTask = self.session.dataTask(with: url) { data, response, error in
        guard let data = data else {
            if let error = error {
                completion(nil, error)
                return
            }
            completion(nil, NSError(domain: "DownloadFailure", code: 0, userInfo:nil))
            return
        }

        guard let response = response as? HTTPURLResponse else {
            completion(nil, NSError(domain: "ResponseFailure", code: 0, userInfo:nil))
            return
        }
        print("http status: \(response.statusCode)")
        let res = String(bytes: data, encoding: .utf8)
        completion(res, nil)
    }
    dataTask.resume()
}

Nếu chúng tôi thực hiện quy trình trên trong Trình mô phỏng iOS, chúng tôi có thể sử dụng Wireshark để kiểm tra xem phản hồi OCSP có dấu thời gian có chữ ký của CA có được ghim vào bắt tay TLS hay không.

Với nslookup revoked.grc.comchúng tôi có được địa chỉ IP của máy chủ và có thể lọc trong Wireshark với ip.addr==4.79.142.205.

Trong ảnh chụp màn hình người ta có thể thấy, chứng chỉ có trạng thái revoked.

Vì vậy, nhìn vào bảng điều khiển Xcodes người ta có thể thấy đầu ra sau:

2019-10-12 21:32:25.734382+0200 OCSPTests[6701:156558] ATS failed system trust
2019-10-12 21:32:25.734526+0200 OCSPTests[6701:156558] Connection 1: system TLS Trust evaluation failed(-9802)
2019-10-12 21:32:25.734701+0200 OCSPTests[6701:156558] Connection 1: TLS Trust encountered error 3:-9802
2019-10-12 21:32:25.734787+0200 OCSPTests[6701:156558] Connection 1: encountered error(3:-9802)
2019-10-12 21:32:25.737672+0200 OCSPTests[6701:156558] Task <12408947-689F-4537-9642-C8F95E86CA62>.<1> HTTP load failed, 0/0 bytes (error code: -1200 [3:-9802])
download failed
error: Error Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred and a secure connection to the server cannot be made." UserInfo={NSURLErrorFailingURLPeerTrustErrorKey=<SecTrustRef: 0x6000037f8510>, NSLocalizedRecoverySuggestion=Would you like to connect to the server anyway?, _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9802, NSErrorPeerCertificateChainKey=(
    "<cert(0x7fda78828200) s: revoked.grc.com i: DigiCert SHA2 Secure Server CA>",
    "<cert(0x7fda7882b200) s: DigiCert SHA2 Secure Server CA i: DigiCert Global Root CA>"
), NSUnderlyingError=0x600000be9170 {Error Domain=kCFErrorDomainCFNetwork Code=-1200 "(null)" UserInfo={_kCFStreamPropertySSLClientCertificateState=0, kCFStreamPropertySSLPeerTrust=<SecTrustRef: 0x6000037f8510>, _kCFNetworkCFStreamSSLErrorOriginalValue=-9802, _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9802, kCFStreamPropertySSLPeerCertificates=(
    "<cert(0x7fda78828200) s: revoked.grc.com i: DigiCert SHA2 Secure Server CA>",
    "<cert(0x7fda7882b200) s: DigiCert SHA2 Secure Server CA i: DigiCert Global Root CA>"
)}}, NSLocalizedDescription=An SSL error has occurred and a secure connection to the server cannot be made., NSErrorFailingURLKey=https://revoked.grc.com/, NSErrorFailingURLStringKey=https://revoked.grc.com/, NSErrorClientCertificateStateKey=0}

iOS hủy bỏ nỗ lực kết nối với máy chủ có lỗi TLS.

Kiểm tra bị thu hồi.badssl.com

bị thu hồi.badssl.com không hỗ trợ dập ghim OCSP.

Nếu chúng ta xem chi tiết chứng chỉ của https://revoking.badssl.com , chúng ta có thể tìm hiểu:

• nó có số sê-ri: 0371B58A86F6CE9C3ECB7BF42F9208FC
• URL CRL là: http://crl3.digicert.com/ssca-sha2-g6.crl

Nếu một người tải xuống tệp .crl (2,5 MB) và phát hành một

openssl crl -inform DER -text -in ssca-sha2-g6.crl | grep 0371B58A86F6CE9C3ECB7BF42F9208FC

người ta có thể thấy rằng chứng chỉ này bị thu hồi thông qua CRL.

Thật thú vị, cả Safari lẫn Chrome và iOS đều không nhận ra trạng thái bị thu hồi này. Chỉ Mozilla Firefox hiển thị thông báo lỗi ( Chứng chỉ của Peer đã bị thu hồi. Mã lỗi: SEC_ERROR_REVOKED_CERTIFICATE ).

Lý do có thể là chứng chỉ đã được gia hạn chỉ một vài ngày trước và do đó vẫn chưa tìm được đường vào tất cả các danh sách thu hồi cục bộ của các trình duyệt và hệ điều hành.