Xung đột giữa các miền được cung cấp bởi SNI và HTTP


22

Gần đây tôi đã chuyển một trang web WordPress với một cửa hàng nhỏ từ nhà cung cấp dịch vụ lưu trữ sang máy chủ của Ubuntu Server 12.04.2 LTS và Apache 2.2.22 của riêng tôi. Tôi yêu cầu SSL cho cửa hàng. Tôi thiết lập một vài vhost đơn giản trên một IP mới cho máy chủ, một liên kết với cổng 80 của IP cụ thể và liên kết khác với cổng 443. Cả có ServerName www.example.comServerAlias example.comtrong cấu hình vhost. Tôi có SSLStrictSNIVHostCheck off.

Trang web đang chạy rất chậm, nhưng đang hoạt động. Tôi đang nhận được những điều sau đây trong nhật ký lỗi của tôi.

[Error] Hostname example.com provided via SNI and hostname www.example.com provided via HTTP are different

Tôi hy vọng rằng sự chậm chạp có liên quan đến thông điệp trên. Bất kỳ ý tưởng về lý do tại sao điều đó xuất hiện và những gì tôi có thể làm về nó?

Câu trả lời:


24

Nhìn vào nhật ký truy cập của bạn (không phải nhật ký lỗi). Với thời gian và ngày xảy ra lỗi, bạn sẽ có thể xác định yêu cầu vi phạm và tìm ra tác nhân người dùng. Trong trường hợp của tôi, đó là một bot:

"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.2)"

Máy chủ của tôi trả lời bằng HTTP 400: Yêu cầu xấu.

Trừ khi tôi nhầm, trong các cuộc đàm phán TLS, khách hàng sẽ gửi tên máy chủ hai lần: một lần TRƯỚC KHI kết nối SSL được thiết lập trong SNI (Chỉ định tên máy chủ) và một lần SAU trong yêu cầu HTTP thực tế. Nếu tên máy chủ không khớp, điều này sẽ chỉ ra máy khách bị hỏng và không liên quan gì đến cách cấu hình máy chủ của bạn.

Có thể họ sẽ sửa bot của họ một ngày nào đó, trong khi đó bạn có thể bỏ qua nó. Tôi nghi ngờ điều này có thể gây ra sự chậm chạp trên máy chủ, trừ khi các yêu cầu đến với tốc độ rất cao.


11

Có thể lỗi này được một số khách hàng gợi ý để kiểm tra lỗ hổng của máy chủ của bạn. Tôi đã thấy rằng một yêu cầu từ đã researchscan367.eecs.umich.edukích hoạt lỗi trên máy chủ mà tôi duy trì. Trong trường hợp này, điều tốt là lỗi xảy ra.

Tôi tò mò loại tấn công nào có thể xảy ra và tôi đã hỏi câu hỏi này trên Sàn giao dịch bảo mật: Loại tấn công nào được ngăn chặn bởi mã lỗi AH02032 của Apache2?


1

Nghe có vẻ như một vấn đề của khách hàng thoạt nhìn ... Trình duyệt nào gây ra vấn đề này?

Thông báo sẽ đề xuất tên máy chủ mà khách hàng gửi trong quá trình kết nối ssl không giống với ứng dụng khách gửi trong yêu cầu HTTPS sau khi lớp SSL kết thúc.


Tôi không biết điều gì gây ra điều này. Lỗi không báo cáo thông tin khách hàng. Tôi chỉ biết tôi đang nhìn thấy điều này thường xuyên. Tôi đã hy vọng rằng ServerAlias ​​là đủ để làm cho nó hạnh phúc vì trên lý thuyết máy chủ biết rằng www.domain.com và domain.com là tương đương.
flickerfly

@flickerfly Vâng, đây là một khách hàng có lỗi và bạn không thể làm gì nhiều trừ khi bạn có thể xác định nó.
Michael Hampton

2
Được rồi, chỉ cần vô hiệu hóa SNI bằng cách xóa chỉ thị NameBasingVirtualhost cho cổng 443. Tôi đoán rằng tôi không cần nó vào thời điểm này. Tôi nghĩ rằng đó là để làm việc.
flickerfly

1

Trong trường hợp của tôi, việc tạo ra một Virtualhost mới với dấu gạch dưới là vấn đề. Tôi có chứng chỉ SSL ký tự đại diện.

Không hoạt động:

<VirtualHost *:443>
        SSLEngine on
        ServerName sub_domain.example.com
        Redirect / https://www.example.com/restofmyredirectlink
</VirtualHost>

Mặc dù Apache đã khởi động lại thành công nhưng tôi đã gặp lỗi HTTP 400. Trong nhật ký lỗi:

[Wed Sep 05 11:28:00.349960 2018] [ssl:error] [pid 19906:tid 140392626808576] AH02031: Hostname sub_domain.example.com provided via SNI, but no hostname provided in HTTP request

Nhưng loại bỏ dấu gạch dưới làm việc:

<VirtualHost *:443>
        SSLEngine on
        ServerName subdomain.example.com
        Redirect / https://www.example.com/restofmyredirectlink
</VirtualHost>

1
Chào mừng đến với ServerFault. Đặt dấu gạch dưới trong tên máy chủ là chống lại RFC và sẽ phá vỡ theo nhiều cách khác nhau. stackoverflow.com/questions/2180465/ trộm
gà con

1
Chính xác! Vì vậy, đó là lý do tại sao bây giờ nó cũng ở đây như là một tài liệu tham khảo.
MS Berends

0

Kiểm tra tệp / etc / hosts của bạn để xem bạn có đang gán tên miền cho địa chỉ IP cục bộ (nội bộ) không. Đừng quên khởi động lại daemon bộ đệm dịch vụ tên sau khi thay đổi / etc / hosts dịch vụ nscd khởi động lại

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.