Tôi đang gặp lỗi: SSL3_GET_RECORD: giải mã không thành công hoặc bản ghi xấu


7

Tôi có máy chủ của riêng mình (nơi tôi đang chạy Apache/2.4.27) và hôm nay tôi nhận ra rằng từ (Brave và Google Chrome - các máy tính khác nhau) tôi nhận được từ trang web của mình lỗi này;

This site can’t provide a secure connection

mywebsite.com sent an invalid response.
ERR_SSL_PROTOCOL_ERROR

Và điều kỳ lạ là tôi nhận được lỗi này cứ sau 5 lần nhấp vào trang web của tôi.

Từ tập tin conf của tôi:

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/mywebsite/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mywebsite/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/mywebsite/chain.pem
SSLCompression off

từ options-ssl-apache.conf;

SSLProtocol             all -SSLv2 -SSLv3
SSLCipherSuite          EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLHonorCipherOrder     on
SSLCompression          off

Tôi đã kiểm tra tệp nhật ký từ trang web nhưng không có gì, cũng không có gì ở đây; /var/log/apache2/error.log

Tôi đang cố gắng tìm ra nguyên nhân gây ra lỗi này, bất kỳ ý tưởng nào tôi có thể tìm thêm thông tin hoặc thậm chí tốt hơn, làm thế nào để giải quyết vấn đề này?

BIÊN TẬP:

Nếu tôi thử openssl s_client -connect mywebsite.com:443, nó sẽ trở lại:

Tôi đang sử dụng: OpenSSL 1.1.0f

CONNECTED(00000003)

...

3073276480:error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac:../ssl/record/ssl3_record.c:469:

KHÁC EDIT:

Như @quadruplebucky đề xuất, tôi đã thay đổi tùy chọn-ssl-apache.conf thành:

SSLProtocol             all -SSLv2 -SSLv3
SSLCipherSuite           HIGH:MEDIUM:!aNULL:!MD5:!SSLv3:!SSLv2:!TLSv1
SSLHonorCipherOrder     on
SSLCompression          off

#SSLSessionTickets       off

Tôi cũng đã cố gắng thêm SSLProtocol all -SSLv2 -SSLv3vào tập tin conf Virtualhost của mình và trong cùng một lúc tôi đã thay đổi một vài thứ ở đây;/etc/apache2/mods-available/ssl.conf

#SSLCipherSuite HIGH:!aNULL
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SSLv3:!SSLv2:!TLSv1

SSLHonorCipherOrder on

#   The protocols to enable.
#   Available values: all, SSLv3, TLSv1, TLSv1.1, TLSv1.2
#   SSL v2  is no longer supported
SSLProtocol all -SSLv2 -SSLv3

BIÊN TẬP:

Sau khi thay đổi LogLevel thành Infonó trả về:

[Sat Jul 08 13:34:53.374307 2017] [ssl:info] [pid 8710] [client] AH02008: SSL library error 1 in handshake (server mywebsite:443)
[Sat Jul 08 13:34:53.374717 2017] [ssl:info] [pid 8710] SSL Library Error: error:140940F4:SSL routines:ssl3_read_bytes:unexpected message
[Sat Jul 08 13:34:53.374750 2017] [ssl:info] [pid 8710] [client] AH01998: Connection closed to child 1 with abortive shutdown (server mywebsite:443)

BIÊN TẬP:

Nếu tôi chạy với tùy chọn -crlf, như thế này:

openssl s_client -crlf -connect mywebsite:443

Tôi không nhận được lỗi?

Một điều nữa nếu tôi thay đổi LogLevel thành gỡ lỗi, trước lỗi đó tôi nhận được điều này:

[Tue Jul 11 23:00:38.641568 2017] [core:debug] [pid 26561] protocol.c(1273): [client 188.64.25.162:23165] AH00566: request failed: malformed request line
[Tue Jul 11 23:00:38.641634 2017] [headers:debug] [pid 26561] mod_headers.c(900): AH01503: headers: ap_headers_error_filter()

Vì vậy, sau đó, lỗi tương tự sẽ xảy ra:

SSL Library Error: error:140940F4:SSL routines:ssl3_read_bytes:unexpected message

openssl version
OpenSSL 1.1.0f  25 May 2017

Không nên có bất kỳ lỗi cấu hình điểm cuối nào gây ra 'giải mã xấu hoặc mac' (cảnh báo 20). Có bất cứ điều gì trong mạng giữa các máy khách này và máy chủ này, như tường lửa, IDS, IPS, DLP hoặc thậm chí là bộ định tuyến 'thông minh' không? Bạn có thể kiểm tra nhiều lần (vì điều này có thể phụ thuộc vào dữ liệu và do đó gần như ngẫu nhiên) kết nối từ chính máy chủ hoặc từ một máy trên cùng phân khúc với máy chủ không?
dave_thndry_085

hiển thị nội dung có liên quan của * .443 virtualhost (toàn bộ virtualhost nếu cần), cũng là đầu ra của "apachectl -S" để chúng tôi có thể loại bỏ cấu hình sai.
ezra-s

thông báo lỗi khiếu nại về SSL v3, nhưng trong cấu hình của bạn, nó bị vô hiệu hóa ...
alexus

Bạn nói rằng bạn đang sử dụng OpenSSL 1.1.0f. Có phải trên cả máy chủ và trên máy mà bạn đã ban hành các lệnh s_client ở trên không? Máy chủ của bạn đang chạy trên nền tảng nào? Bạn có thể muốn xem lỗi có xảy ra với các mật mã cụ thể không, ví dụ như điều gì xảy ra nếu bạn thêm "-codes AES128-SHA" vào cuối lệnh s_client của bạn?
Matt Caswell

ninjaed: @alexus: tên hàmtệp và một số chữ ssl3*SSL3*trong OpenSSL cũng được sử dụng cho TLS (1.0 đến 1.2) vì sự tương đồng kỹ thuật giữa các giao thức đó. user134969: 'chiều dài quá ngắn' cũng không bao giờ được gây ra bởi bất kỳ cấu hình nào. Nếu điều đó có thể lặp lại, vui lòng thử lấy s_client -debug(với RSA đơn giản -ciphernếu bạn không làm điều đó trên máy chủ) và chụp hình dây dẫn cho cùng một sự kiện để chúng tôi có thể xem dữ liệu dây thực tế và so sánh với dữ liệu mà chương trình nhìn thấy.
dave_thndry_085

Câu trả lời:


8

Bạn không thể nhận ra lỗi đó nếu máy chủ của bạn đang đàm phán SSLv3 hoặc TLSv1 (bạn có thể muốn xem câu hỏi này trên Unix & Linux và đảm bảo rằng nó bị vô hiệu hóa ở mọi nơi trong apache ...) --- 1.1.0f mã nguồn ở đây trên GitHub cố tình làm mờ hai ...

   if (enc_err < 0) {
    /*
     * A separate 'decryption_failed' alert was introduced with TLS 1.0,
     * SSL 3.0 only has 'bad_record_mac'.  But unless a decryption
     * failure is directly visible from the ciphertext anyway, we should
     * not reveal which kind of error occurred -- this might become
     * visible to an attacker (e.g. via a logfile)
     */
    al = SSL_AD_BAD_RECORD_MAC;
    SSLerr(SSL_F_SSL3_GET_RECORD,
           SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC);
    goto f_err;
}

Vì vậy, bạn có thể muốn sắp xếp lại bộ mật mã của mình:

SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SSLv3:!SSLv2:!TLSv1

Bài đăng này trên Askubfox về lỗ hổng POODLE có một danh sách tài nguyên tuyệt vời để kiểm tra SSL và hệ thống ống nước.

Trình tạo cấu hình Mozilla là một dịch vụ công cộng tuyệt vời .

Nhận xét "nhận lỗi này mỗi lần nhấp chuột thứ năm" là một chút lạ. Bạn có nghĩa là nhấp chuột , hoặc mỗi dòng thứ năm là một yêu cầu xấu trong nhật ký? Hãy thử bắt đầu apache đơn luồng (cờ -X) và xem nếu điều đó làm điều tương tự ... hoặc có thể thiết lập SSLSessionTickets off.

Suy nghĩ của tôi ở đây là loại bỏ sự phân luồng và tính nhất quán của phiên / bộ đệm / bộ đệm là nguồn gây rắc rối. Chạy apache đơn luồng (bắt đầu bằng cờ -X) là một cách để thực hiện điều này, một cách khác là đặt MaxClients=1(ít nhất là với mô hình MPM). Vé phiên đã từng là một rắc rối trong quá khứ với TLSv1.2 và chúng được bật theo mặc định, đây là lý do đằng sau SSLSessionTickets off(lưu ý đây là một phần của thông báo SSL "Server Hello", không phải cookie phiên hoặc tương tự). Lỗi 'mỗi lần nhấp chuột thứ năm' vẫn làm phiền tôi - Tôi không thể không nhận thấy rằng hầu hết các trình duyệt sẽ xử lý bốn yêu cầu tài nguyên trong một ... và mở một kết nối mới (bắt tay ssl mới, v.v.) cho lần thứ năm ... không có gói chụp, thật khó để nói điều gì đang thực sự xảy ra.

Có vẻ như bạn đã loại bỏ đàm phán mật mã là nguồn gây ra lỗi (bạn có thể nhân đôi điều kiện lỗi theo thông số kỹ thuật mật mã hạn chế hơn nhiều, trừ khi tôi nhầm). Tôi sẽ tò mò muốn biết liệu bạn có thể kích hoạt lỗi hay không bằng cách đàm phán lại SSL (chỉ với các cú đá, nói): openssl s_client -connect server:443và sau đó nhập 'R', xem nhật ký nói gì.
Đồng thời xem bộ đệm ẩn phiên có hoạt động với -reconnecttùy chọn s_client không.
Một cái gì đó phải khác về bối cảnh nhận cho các yêu cầu SSL và có vẻ như cách tốt nhất để tìm ra điều đó (thiếu kiểm tra từng byte một về những gì đi qua dây, có thể khó ẩn danh) giới hạn kích thước của những gì nghe (có nghĩa là, số lượng người nghe).

Các công cụ sửa lỗi khác tôi sẽ thử (giả sử đăng tải gói chụp không nằm trong câu hỏi ....)
- ssltap (trong libnss3-toolstrên ubfox )
- cipherscan
- sslscan

CẬP NHẬT Chọc
vào điều này thông qua ssltap trông rất khủng khiếp như lỗi OpenSSL # 3712 xuất hiện lại (về cơ bản đàm phán lại trong khi đọc / ghi, về cơ bản). Tìm kiếm một cách giải quyết tốt sẽ không giết chết hiệu suất. Công cụ thú vị!


1
Tôi cũng sẽ chơi với các khai báo SSLCodesSuite rõ ràng hơn (dọc theo dòng của cấu hình Mozilla tạo ra), đặt LogLevel thành thông tin hoặc gỡ lỗi, tcpdump / wireshark pcaps, vân vân, bất cứ điều gì để tìm hiểu những gì đang thực sự xảy ra.
quadruplebucky

1
Tại sao bạn không thử một công cụ như cipherscan github.com/mozilla/cipherscan hoặc sslscan github.com/rbsec/sslscan (cũng trong nhiều repos) để cố gắng tìm hiểu điều gì đang thực sự xảy ra trước khi thoái lui?
quadruplebucky

Với SSLProtocol -SSLv3kết nối chắc chắn không phải là SSL3. Hãy nhớ trong các hàm OpenSSL (và các tệp nguồn) được đặt tên bằng ssl3 vẫn là một phần của tất cả các giao thức TLS lên đến 1.2. Xóa các mật mã SSLv3 (và chỉ TLSv1 trong 1.1.0) thực sự ngăn chặn bất kỳ giao thức nào dưới TLS1.2 được đàm phán, nhưng với các trình duyệt cập nhật sẽ ổn.
dave_thndry_085

@ user134969: để wireshark giải mã các kết nối này (và do đó sẽ được trợ giúp ở đây), bạn cần (tạm thời) hạn chế trao đổi khóa thành RSA đơn giản; việc này được thực hiện dễ dàng nhất ở phía Apache với SSLCiphers RSA+AES. (Và cung cấp tệp tin máy chủ riêng tư trong Chỉnh sửa / Tùy chọn / Giao thức / SSL.) Chrome được sử dụng để khiếu nại về RSA đơn giản (nghĩa là không phải PFS) nhưng hiện tại tôi đã kiểm tra lại và tôi dường như rất vui.
dave_thndry_085

@quadruplebucky bạn có thể chỉ cho tôi vị trí của "ssl3_record.c" trong hệ thống là gì không?
dùng134969

6

Tôi đã nhìn thấy điều này trước đây, thực tế đã có điều này trước đây.

Câu trả lời trong trường hợp của tôi đã kết thúc cực kỳ tinh tế.

Bộ điều hợp mạng đã bật TCP Segment Offloading, do lỗi của một số hình thức là xáo trộn (hoặc cắt bớt, không thể nhớ) vài byte cuối cùng của một số tin nhắn - điều này sau đó đã khiến MAC trên các bản ghi SSL bị lỗi.

Đó là một máy ảo trên VMWare.

Tôi sẽ thử vô hiệu hóa TSO / GSO / GRO trong môi trường của bạn và xem vấn đề có biến mất không.

ethtool -K eth0 tso off gro off gso off ufo off

Nó trả về: Không thể thay đổi udp-phân mảnh-giảm tải
user134969

Làm tương tự nhưng bỏ qua 'ufo off'
Matthew Ife

1
Một điều khá hợp lý khác để tìm kiếm có thể gây ra sự cắt xén gói là các vấn đề MTU (khung jumbo được bật khi không nên) hoặc MSS cần có kẹp trên TCP nếu bạn gửi dữ liệu của mình xuống một đường hầm.
Matthew Ife

3

Có một số điều kỳ lạ với OpenSSL và đa luồng. Bạn sử dụng MPM nào? Nếu điều này liên quan đến đa luồng, "prefork" sẽ an toàn trong khi "worker" và "event" có thể bị ảnh hưởng.

Nếu hồ sơ tải của bạn cho phép, có lẽ bạn có thể thử chuyển sang prefork và xem vấn đề còn tồn tại không.


vì vậy ít nhất đa luồng được loại trừ :)
Andreas Rogge

0

Trước tiên hãy chắc chắn rằng chrome được cập nhật. Các phiên bản cũ hơn có vấn đề với một số mật mã. Có vấn đề với bản thân crom với các trang web phổ biến như amazon, v.v.

Thứ hai, lời khuyên để cấm các giao thức trong "danh sách mật mã" mà bạn đã theo dõi là một ý tưởng rất tồi bởi vì nó sẽ không cấm các giao thức, nó sẽ cấm hầu hết các mật mã bao gồm cả các giao thức hoạt động "kể từ" SSLv3 (nhưng không có nghĩa là bạn đang bật SSL3 nếu bạn cho phép mật mã SSLv3), sử dụng danh sách tổng quát hơn do trình tạo cấu hình SSL SSL cung cấp để tương thích (lưu ý SSLv2 không còn tồn tại hoặc được hỗ trợ trong httpd hoặc openssl vì vậy không có lý do gì để cấm rõ ràng nữa) và có lẽ sự kết hợp trước đó của bạn quá nghiêm ngặt , hãy thử cái này:

SSLProtocol             all -SSLv3
SSLCipherSuite          ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS

Nếu bạn vẫn gặp sự cố, hãy bật gỡ lỗi cho SSL và xem httpd nói gì (chỉ gửi 1 hoặc hai lần thử và vô hiệu hóa nhật ký này, điều này quá ồn ào):

LogLevel ssl:trace3

Sidenotes: Bạn cũng có thể tiếp tục và loại bỏ SSLCertertChainFile vì lệnh đó không được chấp nhận trong 2.4. Bạn có thể thêm chuỗi SSLCertertFile và sắp xếp tất cả các chứng chỉ từ lá sang gốc hoặc thậm chí thay đổi SSLCertertChainFile thành SSLCACertertFile (mặc dù chứng chỉ này chủ yếu được sử dụng cho SSL auth).

Bạn cũng nên thêm (nếu bạn chưa có) để thêm:

SSLRandomSeed startup file:/dev/urandom 2048
SSLRandomSeed connect file:/dev/urandom 2048
SSLSessionCache shmcb:/path/to/log/ssl_gcache_data(512000)

Chỉnh sửa: Theo dõi cuộc trò chuyện của chúng tôi, hãy dùng đến để kiểm tra cài đặt openssl và / hoặc nếu nó thực sự là phiên bản tương tự mà httpd của bạn sử dụng:

Ban hành lệnh này và hãy xem nó nói gì: openssl ciphers -v 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS'

Ngoài ra để đảm bảo phiên bản openssl là phiên bản chính xác chạy này:

openssl version

Không, không giải quyết được - kiểm tra chỉnh sửa của tôi, tôi đã đăng nhật ký khi sử dụng ssl: track3 ...
user134969

Là phiên bản được biên dịch trước hoặc biên dịch thủ công?
ezra-s

@ user134969 Tôi đang nối thêm một lệnh để bạn có thể xem liệu bạn có nhận được mật mã hoặc đủ mật mã trong kho của bạn không, nếu có vấn đề với nó.
ezra-s
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.