Lỗi bắt tay SSL là gì?

Scrapeless Proxies cung cấp định tuyến cho các HTTP client có kết nối đích bảo mật vẫn cần thương lượng TLS thành công.

Lỗi bắt tay SSL có nghĩa là client và đối tác bảo mật không thể hoàn tất quá trình thương lượng cần thiết để thiết lập kết nối an toàn. HTTPS hiện đại dùng TLS, mặc dù nhãn SSL cũ vẫn phổ biến trong thông báo lỗi. Lỗi có thể liên quan đến khả năng tương thích giao thức, danh tính máy chủ, xác thực máy khách hoặc trao đổi bị gián đoạn, vì vậy cảnh báo cụ thể và giai đoạn cuối cùng hoàn tất sẽ quyết định hướng điều tra.

Những gì bắt tay TLS thiết lập

Một lần bắt tay TLS thiết lập ngữ cảnh bảo mật đã được thương lượng để client và server sử dụng. Nó bao gồm các lựa chọn giao thức tương thích và việc xác thực cần thiết theo chế độ đã chọn. Nếu trao đổi không thể hoàn tất, dữ liệu ứng dụng được bảo vệ thông thường sẽ không thể tiếp tục như dự định.

Đặc tả giao thức TLS và bắt tay định nghĩa hành vi thương lượng và cảnh báo. Một cảnh báo có thể cung cấp bằng chứng hữu ích, nhưng “handshake failed” trong log ứng dụng thường chỉ là một lớp bọc quanh một vấn đề cụ thể hơn. Hãy giữ lại lý do gốc và thông tin về việc client có nhận được chứng chỉ hoặc đã thương lượng giao thức hay chưa.

Thuật ngữ SSL vẫn tồn tại trong thông báo hướng tới người dùng và tên thư viện, ngay cả khi kết nối sử dụng TLS. Đừng kết luận rằng một đầu cuối hiện đại đang chạy giao thức SSL lỗi thời chỉ dựa trên cách diễn đạt lỗi. Hãy kiểm tra cấu hình thực tế của client và server nếu phiên bản giao thức có liên quan đến lỗi.

Đối với hệ thống thu thập, lỗi bắt tay là một kết quả chẩn đoán kết nối. Nó không phải là HTTP status do ứng dụng đích trả về và không phải là bằng chứng về một tài nguyên rỗng hợp lệ. Bản ghi nguồn nên được giữ ở trạng thái chưa được chấp nhận cho đến khi kết nối an toàn và các kiểm tra nội dung yêu cầu được hoàn tất.

Tương thích giao thức và sai listener

Thương lượng TLS yêu cầu các lựa chọn tương thích giữa client và đối tác bảo mật. Một server bị giới hạn vào cấu hình mà client không hỗ trợ có thể thất bại trước khi dữ liệu ứng dụng được trao đổi. Hãy so sánh cấu hình được hỗ trợ của đúng bản dựng client và listener đang hoạt động thay vì áp dụng chung cách sửa “bật tất cả phiên bản”.

Một listener sai có thể tạo ra những triệu chứng cấp cao tương tự. Nếu client mong đợi TLS nhưng cổng được cấu hình lại phục vụ HTTP thuần hoặc một giao thức khác, trao đổi có thể thất bại trước khi nó có thể cung cấp bằng chứng chứng chỉ hữu ích. Hãy xác minh cùng lúc scheme dịch vụ và listener đang hoạt động. Một số cổng tự thân không bảo đảm về giao thức.

Với một endpoint do bạn sở hữu, hãy kiểm tra edge hoặc reverse proxy nhận kết nối. Listener nội bộ của ứng dụng có thể khác với listener bảo mật công khai. Một triển khai có thể có mã ứng dụng được cấu hình đúng trong khi lớp kết thúc công khai lại trình bày các cài đặt không tương thích. Hãy chẩn đoán đúng đối tác mà client gặp phải khi lỗi xảy ra.

Hãy sử dụng các cài đặt bảo mật đang được hỗ trợ thay vì bật lại các thuật toán lỗi thời như một cách sửa toàn diện. Lỗi tương thích được khắc phục tốt nhất bằng cách đưa client và dịch vụ dự kiến vào một cấu hình chung chấp nhận được. Giữ tài liệu về chính sách kết quả để một image hoặc thay đổi edge trong tương lai không âm thầm gây ra lỗi không khớp trở lại.

Xác thực chứng chỉ là một dạng lỗi bắt tay có thể xảy ra

Xác thực chứng chỉ có thể dừng bắt tay khi client không thể xác thực máy chủ theo chính sách của nó. Chứng chỉ có thể không hợp lệ với hostname được yêu cầu, khoảng thời gian hiệu lực, hoặc chuỗi nhà phát hành. Đây là chẩn đoán hẹp hơn so với một lỗi bắt tay chung chung.

Đặc tả danh tính dịch vụ TLS giải thích mối liên hệ giữa tên dịch vụ dự định và danh tính được đối tác bảo mật trình bày. Hãy giữ nguyên hostname chính xác đã dùng trong yêu cầu lỗi. Kết nối tới cùng một địa chỉ nhưng với tên dịch vụ khác có thể hiển thị một ngữ cảnh danh tính khác và không được tự động xem là phép thử tương đương.

Client có thể nhận chứng chỉ rồi mới từ chối nó, hoặc thương lượng có thể thất bại trước khi có bất kỳ chứng chỉ nào được nhận. Hãy ghi lại khác biệt này. Nếu lỗi xảy ra trước khi tồn tại bằng chứng chứng chỉ, kết luận rằng chứng chỉ hết hạn là không được hỗ trợ. Nếu bước xác thực báo rõ không khớp hoặc lỗi nhà phát hành, hãy điều tra trực tiếp kiểm tra đó.

Ví dụ xác minh chứng chỉ TLS trong curl minh họa lý do tại sao cấu hình trust của client lại quan trọng. Trình duyệt, client dòng lệnh và runtime của container có thể dùng các nguồn trust khác nhau. Hãy so sánh những gì mỗi client thực sự nhận và tin cậy trước khi thay đổi hành vi xác thực. Một lần truy cập bằng trình duyệt thành công không yêu cầu HTTP client bỏ qua lỗi chứng chỉ riêng của nó.

Chứng chỉ máy khách và xác thực hai chiều

Một TLS server có thể yêu cầu client xác thực bằng chứng chỉ. Yêu cầu này tách biệt với mật khẩu proxy hoặc đăng nhập website thông thường. Một chứng chỉ máy khách thiếu, không phù hợp hoặc không được ủy quyền có thể ngăn phiên bảo mật hoàn tất ngay cả khi chứng chỉ máy chủ hợp lệ.

Kiểm tra các yêu cầu xác thực được ghi trong tài liệu của dịch vụ trước khi cung cấp chứng chỉ máy khách. Đối với một API nội bộ thuộc sở hữu, hãy xác minh rằng chứng chỉ và khóa riêng tương ứng có sẵn cho tiến trình dự định thông qua cơ chế bí mật đã được phê duyệt. Chỉ riêng tệp chứng chỉ không đủ để khẳng định máy khách có thể sử dụng khóa riêng của nó.

Giữ thông tin xác thực của máy khách trong phạm vi dịch vụ được ủy quyền. Không xuất khóa riêng vào bản ghi hỗ trợ hoặc đặt chúng trong nhật ký tự động hóa trình duyệt chung. Một bản ghi sự cố hữu ích có thể xác định tham chiếu không bí mật của chứng chỉ đã cấu hình, yêu cầu của dịch vụ và loại lỗi mà không để lộ vật liệu khóa.

Đối với một tài nguyên bên thứ ba công khai, yêu cầu chứng chỉ máy khách bất ngờ có thể cho thấy nhầm điểm cuối hoặc một ranh giới dịch vụ bị hạn chế. Xác minh URL công khai dự định và các yêu cầu truy cập. Một bộ thu thập nên ghi lại điều kiện truy cập đó thay vì giả định rằng bắt tay có thể được sửa thông qua định tuyến ẩn danh.

Xác định Đối Tượng Bảo Mật Trên Tuyến Proxy

Một tuyến proxy có thể bao gồm nhiều hơn một kết nối bảo mật. Một proxy nói TLS có trao đổi bảo mật máy khách‑đến‑proxy; một đích HTTPS có trao đổi bảo mật với đích, thường ở bên trong đường hầm. Một cổng kiểm tra đã được phê duyệt có thể kết thúc và tạo lại lưu lượng bảo mật. Hãy đặt tên đối tượng ngang hàng mà quá trình bắt tay đã thất bại.

Sự phân biệt giữa kiểm tra TLS và đường hầm mờ mang lại ngữ cảnh hữu ích để diễn giải cấu trúc đó. Một đường hầm thông thường có thể chuyển tiếp các byte mã hóa của đích mà không phải là điểm cuối TLS của đích. Một lỗi trước khi đường hầm mở thuộc về thiết lập proxy, trong khi lỗi sau thời điểm đó có thể liên quan đến trao đổi bảo mật với đích.

Sử dụng cấu hình kết nối proxy Scrapeless hiện tại để xác lập các giá trị truyền tải và xác thực của cổng. Scheme HTTPS của đích không tự động chọn scheme cổng bảo mật. Sự không khớp giữa cấu hình proxy của máy khách và listener được hỗ trợ có thể ngăn chuỗi bắt tay mong đợi bắt đầu.

Sau khi xác nhận các giai đoạn cổng và đường hầm, hãy kiểm tra kết quả TLS của đích. Ghi lại tên máy chủ của đích, danh tính đối tượng bảo mật, kết quả chứng chỉ và cảnh báo hoặc lỗi phía máy khách nếu có. Mục tiêu là lưu giữ kết nối nào đã thất bại thay vì gộp cả tuyến proxy thành “SSL bị hỏng.”

So Sánh Lỗi Bắt Tay Với Các Sự Kiện Liền Kề

Lỗi bắt tay là một danh mục rộng, vì vậy so sánh với các giai đoạn liền kề giúp xác định liệu chẩn đoán TLS thực sự có phải là nhiệm vụ tiếp theo hay không.

Nếu tra cứu tên thất bại, một kết nối bảo mật có thể không bao giờ được thử. Nếu proxy từ chối CONNECT, quá trình bắt tay với đích có thể không bao giờ bắt đầu. Nếu TLS hoàn tất và đích gửi trạng thái lỗi ứng dụng, đó là một kết quả HTTP. Giữ mỗi quan sát trong giai đoạn mà nó đã xảy ra.

Thời gian chờ trong quá trình thiết lập cũng cần bằng chứng về thời gian và đối tượng ngang hàng. Nó không xác định được một vấn đề cụ thể về mật mã hay chứng chỉ. So sánh thời hạn của máy khách với các giai đoạn thiết lập đã đo, và kiểm tra xem có phản hồi hoặc cảnh báo tồn tại hay không. Một trao đổi không được trả lời và một từ chối thương lượng rõ ràng là hai bằng chứng khác nhau.

Xây Dựng Bản Ghi Chẩn Đoán Kết Nối Bảo Mật

Một bản ghi hữu ích cho lỗi bắt tay SSL bao gồm authority của đích, đối tượng bảo mật thực tế, tuyến, bản dựng máy khách và giai đoạn cuối cùng hoàn tất. Thêm lỗi gốc và loại xác thực chứng chỉ khi được cung cấp. Tránh lưu trữ một trạng thái HTTP phỏng đoán cho một trao đổi chưa bao giờ tới được HTTP.

Đối với hạ tầng thuộc sở hữu, hãy đối chiếu sự kiện phía máy khách với nhật ký TLS ở biên và trên máy chủ. So sánh các máy khách lỗi và hoạt động được dưới cùng cấu hình dịch vụ dự định. Nếu chúng khác nhau, hãy kiểm tra hỗ trợ giao thức, nguồn tin cậy, xác thực máy khách và điểm cuối mà mỗi bên thực sự đã tới. Sử dụng các khác biệt để chọn một giả thuyết có thể được kiểm tra.

Đối với thu thập web, hãy giữ chẩn đoán bắt tay tách biệt với đầu ra trích xuất. Một kết nối bảo mật thất bại không nên xóa bản ghi hợp lệ cuối cùng của nguồn hoặc tạo bản thay thế chứa trang lỗi. Lưu trữ một sự kiện bắt giữ thất bại và bảo toàn trạng thái nguồn đã biết cho đến khi quy trình làm việc có được bằng chứng mới được chấp nhận.

mạng proxy Scrapeless phù hợp với các máy khách cần định tuyến được quản lý trong khi vẫn giữ việc xác thực TLS của riêng họ. Xem lại các gói Scrapeless hiện tại so với yêu cầu về tuyến và lưu lượng. Định tuyến được quản lý có thể thay đổi đường đi được dùng cho so sánh có kiểm soát, nhưng nó không thể đảm bảo cấu hình bảo mật của đích là chính xác.

Hoàn Tất Thương Lượng Với Chính Sách Bảo Mật Dự Định

Giải quyết lỗi bắt tay SSL có nghĩa là máy khách và đối tượng bảo mật dự định hoàn tất một trao đổi tương thích, đã được xác thực. Sửa listener, cấu hình giao thức, danh tính dịch vụ, nguồn tin cậy hoặc thiết lập chứng chỉ máy khách được thể hiện qua bằng chứng.

Xác thực tài nguyên gốc thông qua tuyến yêu cầu với xác minh được bật. Sau đó kiểm tra phản hồi HTTP và danh tính nội dung. Một bắt tay thành công là một cột mốc kết nối cần thiết, trong khi một bản chụp nguồn sử dụng được còn đòi hỏi các giai đoạn sau đó cũng phải hoàn tất.