Lỗi xác thực của Google khi truy cập điểm cuối mã thông báo từ JVM

Question

Chúng tôi chạy một ứng dụng web với chương trình phụ trợ JVM (Java 7 cập nhật 75; mã ở Scala, nhưng tôi không tin điều này là có liên quan). Chúng tôi sử dụng Google để xác thực thông qua Oauth.

Đã có một số ngày trong vài tháng qua mà chúng tôi đã không liên tục không thể xác thực người dùng.

Chuyển hướng đến và từ Google thành công, nhưng khi chúng tôi cố gắng gọi số token_endpoint tại https://www.googleapis.com/oauth2/v4/token để xác thực xác thực, đôi khi chúng tôi nhận được ngoại lệ sau: javax.net.ssl.SSLHandshakeException: server certificate change is restrictedduring renegotiation.

Nhận xét này về một câu hỏi khác khiến tôi tìm thấy lỗi JDK có thể biểu hiện như ngoại lệ này (What means "javax.net.ssl.SSLHandshakeException: server certificate change is restrictedduring renegotiation" and how to prevent it?).

giả thuyết làm việc của tôi là:

Lỗi (https://bugs.openjdk.java.net/browse/JDK-8072385) có nghĩa là chỉ mục đầu tiên trong Subject Alternative Name danh sách (SAN) được kiểm tra. Ngoại lệ trên được ném khi tên máy chủ được xác minh nằm trong danh sách SAN, nhưng không phải ở đầu danh sách.

Hôm qua (ngày 27 tháng 5 năm 2015 từ), chúng tôi đã thấy hai chứng chỉ khác nhau được cung cấp liên tục từ www.googleapis.com. Đầu tiên (nối tiếp 67:1a:d6:10:cd:1a:06:cc) có danh sách SAN là DNS:*.googleapis.com, DNS:*.clients6.google.com, DNS:*.cloudendpointsapis.com, DNS:cloudendpointsapis.com, DNS:googleapis.com trong khi thứ hai (nối tiếp 61:db:c8:52:b4:77:cf:78) có danh sách SAN là: DNS:*.storage.googleapis.com, DNS:*.commondatastorage.googleapis.com, DNS:*.googleapis.com.

Do lỗi trong JVM, chúng tôi có thể xác thực chứng chỉ đầu tiên, nhưng ngoại lệ được ném với chứng chỉ thứ hai (mặc dù hoàn toàn hợp lệ) vì *.googleapis.com không phải là mục nhập đầu tiên trong danh sách SAN.

Bản sửa lỗi chưa được phát hành 7u85 (không đề cập đến thời điểm này sẽ có sẵn).

Tôi đã hạ cấp một nút duy nhất của cụm thành 7u65, nhưng chứng chỉ dường như được hoàn nguyên vào khoảng thời gian chúng tôi thực hiện điều này (lỗi cuối cùng chúng tôi thấy là 22: 20GMT). .

Có ai khác đã trải nghiệm điều này hoặc điều gì đó tương tự và có bất kỳ giải pháp nào khác ngoài việc hạ cấp (hạ cấp loại bỏ các kiểm tra SSL/TLS khác) không?

Answer 1

Tôi không thực sự chắc chắn rằng sự cố của bạn có liên quan đến lỗi JVM.

Có một sửa chữa trong Java 6 trở lên cho CVE-2014-6457, "Ba Handshake tấn công chống lại các kết nối TLS/SSL (JSSE, 8.037.066)", ngăn ngừa chứng chỉ ngang hàng thay đổi trong quá trình đàm phán lại.

Vấn đề giải thích:

Một lỗ hổng bảo mật trong tất cả các phiên bản của tầng Transport Security (TLS) Nghị định thư (bao gồm Secure Socket Layer cũ (SSLv3)) có thể cho phép Man-In-The-Trung Các cuộc tấn công kiểu (MITM) khi được chọn văn bản thuần túy được tiêm dưới dạng tiền tố cho kết nối TLS. Lỗ hổng này không cho phép kẻ tấn công giải mã hoặc sửa đổi thông tin liên lạc mạng bị chặn sau khi khách hàng và máy chủ có đàm phán thành công phiên giao dịch giữa họ.

Tuy nhiên, nếu chứng chỉ có khả năng thay đổi giống với giấy chứng nhận tương tự làm kết quả cuối cùng được cho phép.

Hai sắc được coi là bình đẳng trong trường hợp này:

• Có một đối tượng tên thay thế quy định tại cả hai giấy chứng nhận đó là một địa chỉ IP và địa chỉ IP trong cả hai giấy chứng nhận là như nhau.
• Có tên thay thế chủ đề được chỉ định trong cả hai chứng chỉ là tên DNS và tên DNS trong cả hai chứng chỉ giống nhau.
• Trường chủ đề và tổ chức phát hành có mặt trong cả hai chứng chỉ và chứa các giá trị chủ thể và tổ chức phát hành giống hệt nhau.

Trong các điều kiện khác (nhận dạng chứng chỉ đã thay đổi) thì ngoại lệ javax.net.ssl.SSLHandshakeException: server certificate change is restricted during renegotiation được nâng lên.

Cách giải quyết:

• Disable đàm phán lại (không khuyến khích) áp dụng đối số JVM sau: -Djdk.tls.allowUnsafeServerCertChange=true nó vô hiệu hóa công tác bảo vệ chứng chỉ máy chủ an toàn.
• Tắt SSLv3 trong kết nối HTTPS đi, Java 7 hỗ trợ TLSv1.1 và TLSv1.2 ở chế độ khách hàng nhưng mặc định sử dụng TLSv1 trong bắt tay TLS. Chúng ta cũng nên sử dụng TLSv1.1 và TLSv1.2 trong TLS chế độ khách hàng trong java 7. Java 8 bật TLSv1.1 và TLSv1.2 ở chế độ máy khách (ngoài SSLv3 và TLSv1) và sử dụng TLSv1.2 theo mặc định trong bắt tay TLS. Nếu bạn đang tạo kết nối theo lập trình và thiết lập một nhà máy socket sử dụng TLS thay vì SSL.

Dù sao, hãy cập nhật bài đăng của bạn bằng mã khách hàng google oauth trước khi gọi token_endpoint để xác thực xác thực để xem điều gì có thể xảy ra.