2015-01-18 23 views
6

Tôi có vấn đề với nginx tôi trên Ubuntu 14.04 LTS. Bất cứ lúc nào tôi nhận được một lỗi nghiêm trọng:nginx lỗi nghiêm trọng với SSL bắt tay

2015/01/18 12:59:44 [crit] 1065#0: *28289 SSL_do_handshake() failed (SSL: error:140A1175:SSL routines:SSL_BYTES_TO_CIPHER_LIST:inappropriate fallback) while SSL handshaking, client: 10.0.2.2, server: 0.0.0.0:443 

Tôi đã kiểm tra phiên bản OpenSSL tôi:

[email protected]:~# ldd `which nginx` | grep ssl 
     libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f39e236b000) 

[email protected]:~# strings /lib/x86_64-linux-gnu/libssl.so.1.0.0 | grep "^OpenSSL " 
OpenSSL 1.0.1f 6 Jan 2014 

Tôi đã tìm kiếm thêm thông tin về nó và thấy rằng nó có thể là vấn đề với phiên bản cũ OpenSSL. Vì vậy, tôi đã cố gắng để biên dịch phiên bản mới nhất:

wget https://www.openssl.org/source/openssl-1.0.1l.tar.gz && tar xzf && cd openssl-1.0.1l 

./config && make && make install 

Tôi cũng đã thay thế OpenSSL tập tin nhị phân cũ với cái mới thông qua liên kết tượng trưng:

ln -sf /usr/local/ssl/bin/openssl `which openssl` 

Sau đó tôi có:

[email protected]:~# openssl version 
OpenSSL 1.0.1l 15 Jan 2015 

Nhưng tôi vẫn có phiên bản cũ trong nginx:

[email protected]:~# strings /lib/x86_64-linux-gnu/libssl.so.1.0.0 | grep "^OpenSSL " 
OpenSSL 1.0.1f 6 Jan 2014 

Tôi không thể tìm thấy bất kỳ libssl mới nào khác trong Ubuntu sau khi cập nhật OpenSSL. Làm cách nào để cập nhật libssl để nginx có thể sử dụng phiên bản mới nhất?

P.S.1. Có thể vấn đề với lỗi nghiêm trọng không phải là về phiên bản OpenSSL.

P.S.2. Tôi nghĩ rằng lỗi crtitical này có thể ảnh hưởng đến toàn bộ Virtual Machine của tôi. Tôi cũng có một vấn đề với "thời gian để thời gian" đâm của VM.

Tôi đã thử rất nhiều điều và bây giờ tôi tuyệt vọng. Stackoverflow xin vui lòng giúp đỡ!

Trả lời

8

...BYTES_TO_CIPHER_LIST:inappropriate fallback) while SSL handshaking, client: 10.0.2.2, server: 0.0.0.0:443

Có vẻ như ai đó đang kiểm tra xem máy chủ có hỗ trợ TLS_FALLBACK_SCSV hay không. Không có gì phải lo lắng về. Ngược lại, điều này có nghĩa là máy chủ của bạn hỗ trợ một tính năng bảo mật hữu ích. Để biết thêm thông tin về TLS_FALLBACK_SCSV và làm thế nào người ta có thể phát hiện các cuộc tấn công hạ cấp SSL như POODLE cách này bạn có thể có một cái nhìn tại http://www.exploresecurity.com/poodle-and-the-tls_fallback_scsv-remedy/.

TLS_FALLBACK_SCSV là một lựa chọn khá mới nhằm phát hiện các cuộc tấn công hạ cấp SSL. Nó cần hỗ trợ trên máy khách và máy chủ. Cũ hơn nginx/OpenSSL và các trình duyệt cũ hơn chỉ đơn giản là không có tùy chọn này vì vậy vấn đề này có thể không được phát hiện và do đó không đăng nhập các phiên bản trước đó. Thông báo này rất quan trọng vì nó có thể cho thấy một nỗ lực tấn công hạ cấp SSL thực sự đối với ứng dụng khách đã bị đánh bại bởi tùy chọn này. Trong thực tế nó có lẽ là một số công cụ thăm dò để hỗ trợ các tùy chọn, như SSLLabs.

Để tham khảo các mã có liên quan từ ssl/ssl_lib.c chức năng ssl_bytes_to_cipher_list:

/* Check for TLS_FALLBACK_SCSV */ 
if ((n != 3 || !p[0]) && 
     (p[n-2] == ((SSL3_CK_FALLBACK_SCSV >> 8) & 0xff)) && 
     (p[n-1] == (SSL3_CK_FALLBACK_SCSV & 0xff))) 
     { 
     /* The SCSV indicates that the client previously tried a higher version. 
     * Fail if the current version is an unexpected downgrade. */ 
     if (!SSL_ctrl(s, SSL_CTRL_CHECK_PROTO_VERSION, 0, NULL)) 
       { 
       SSLerr(SSL_F_SSL_BYTES_TO_CIPHER_LIST,SSL_R_INAPPROPRIATE_FALLBACK); 
       if (s->s3) 
         ssl3_send_alert(s,SSL3_AL_FATAL,SSL_AD_INAPPROPRIATE_FALLBACK); 
       goto err; 
       } 
     p += n; 
     continue; 
     } 
+0

Tôi chưa từng gặp vấn đề này trước đây. Trước đó tôi đã sử dụng Debian với nginx cũ hơn. Nếu vấn đề này được gắn thẻ là quan trọng trong nhật ký nginx thì điều gì quan trọng về nó? Câu trả lời của bạn rõ ràng là không có vấn đề gì cả. Tôi không hiểu. – MegaKaskaskas

+0

Tôi đã cập nhật câu trả lời để bao gồm thêm thông tin. –

+0

Cảm ơn bạn đã giải thích vấn đề @Steffen Ullrich. Sau khi cập nhật thủ công gói OpenSSL và nginx trên Ubuntu, sự cố vẫn xảy ra. Trong hoạt động hàng ngày, nginx tạo ra hàng chục nhật ký lỗi với các nội dung sau: 2015/01/27 10:06:15 chiều [crit] 730 # 0: * 263,168 SSL_do_handshake() không thành công (SSL: lỗi: 140A1175: các thường trình SSL: SSL_BYTES_TO_CIPHER_LIST: Dự phòng không phù hợp) trong khi bắt tay SSL, máy khách: 10.0.2.2, máy chủ: 0.0.0.0:443 – MegaKaskaskas

0

nó có ảnh hưởng đến khách hàng gửi yêu cầu? Theo sự hiểu biết của tôi, khách hàng gửi yêu cầu đầu tiên của mình đến máy chủ của chúng tôi, nhưng có thể số dư tải của chúng tôi trên một tải cao xảy ra kết nối đầu tiên không thành công. Và sau đó khách hàng cố gắng hạ cấp phiên bản giao thức của nó để thử lại kết nối, nhưng vì máy chủ của chúng tôi hỗ trợ TLS_FALLBACK_SCSV, nó sẽ làm ssl bắt tay không thành công.

Vì vậy, khách hàng sẽ không có cơ hội kết nối máy chủ của chúng tôi sau này?

Nếu số dư tải của chúng tôi phục hồi tải bình thường, khách hàng sẽ có cơ hội thử kết nối lại với phiên bản giao thức cao thành công không?

Các vấn đề liên quan