Chỗ bị tổn thương trong giao thức SSL/TLS

Vulnerability in SSL/TLS protocol

5 November 2009, 16:10

Theo: http://www.h-online.com/security/news/item/Vulnerability-in-SSL-TLS-protocol-851478.html

Bài được đưa lên Internet ngày: 05/11/2009

Lời người dịch: Lỗi trong giao thức SSL/TLS có thể gây ảnh hưởng cho cả máy chủ web IIS của Microsoft và các máy chủ web httpd của Quỹ Apache, và OpenSSL.

Theo các báo cáo, những chỗ bị tổn thương trong giao thức SSL/TLS có thể bị khai thác bởi những kẻ tấn công để chèn nội dung vào các kết nối an ninh. Nếu điều này là đúng, thì nó có thể ảnh hưởng tới HTTPS và tất cả các giao thức khác mà chúng sử dụng TLS cho an ninh, bao gồm cả IMAP. Những hiệu ứng chính xác về vấn đề này còn chưa được bàn luận trong các báo cáo. Tuy nhiên, nó có thể có khả năng điều khiển nội dụng HTML từ các website trong khi truyền dữ liệu và, ví dụ, tiêm vào các mã nguồn độc hại.

Sự nan giải của vấn đề là thay vì một triển khai cài đặt không hoàn thiện, một khiếm khuyết thiết kế trong giao thức TLS khi tạo lại các thông số cho một kết nối TLS đang tồn tại. Điều này xảy ra khi, ví dụ, một máy trạm muốn truy cập tới một vùng an ninh trên một máy chủ web mà nó đòi hỏi các xác thực máy trạm. Khi máy chủ thiết lập thì điều đó là trường hợp này, và nó bắt đầu một sự thảo luận lại để có được xác thực máy trạm phù hợp. Yêu cầu ban đầu được thực hiện lại trong lúc thảo luận lại này dường như náo đã được xác thực bởi sự xác thực của máy trạm, nhưng nó lại không. Phát hiện vấn đề này mô tả điều này như một “lỗ hổng xác thực”.

Theo báo cáo, một cuộc tấn công có thể mở ra như sau:

Một kẻ tấn công cắt kết nối giữa máy chủ và máy trạm và thiết lập một kết nối HTTPS với máy chủ. Kẻ này bắt đầu giữ tạm thời kết nối tới máy trạm trong một tình trạng không hoàn thiện. Kẻ này gửi cho máy chủ một yêu cầu HTTPS cho một vùng an ninh - máy chủ sau đó thảo luận lại một kết nối mới hoàn toàn và yêu cầu xác thực máy trạm. Kẻ này chuyển tiếp tất cả các gói sau đó giữa máy trạm và máy chủ không được thay đổi. Cuối cùng, yêu cầu HTTP của kẻ tấn công - là một yêu cầu POST cho một dạng được bảo vệ - được chạy dường như nó tới từ máy trạm.

Vấn đề này đã được chỉ ra để tồn tại trong các phiên bản mới nhất của IIS của Microsoft và các máy chủ web httpd của Quỹ Apache, và OpenSSL cũng sẽ bị ảnh hưởng. Một miếng vá đã từng được triển khai bởi Ben Laurie, nhưng nó chỉ dừng việc thảo luận lại và không giải quyết vấn đề một cách thực sự. Một giải pháp dài hạn đang được thảo luận. Một khả năng có thể đưa ra những xác thực máy trạm sớm, trước một URL cụ thể nào đó được yêu cầu. Nhóm Làm việc Có trách nhiệm cho Kênh TLS của IETF cũng được cho là sẽ làm việc về một dự thảo, mà nó có thể đã có chứa một giải pháp.

According to reports, vulnerabilities in the SSL/TLS protocol can be exploited by attackers to insert content into secure connections. If this is correct, it would affect HTTPS and all other protocols which use TLS for security, including IMAP. The precise effects of the problem are not discussed in the reports. It would, however, appear to be possible to manipulate HTML content from websites during data transfer and, for example, inject malicious code.

The crux of the problem is, rather than a flawed implementation, a design flaw in the TLS protocol when renegotiating parameters for an existing TLS connection. This occurs when, for example, a client wants to access a secure area on a web server which requires the requesting client certificates. When the server establishes that is the case, it begins a renegotiation to obtain the appropriate client certificate. The original request gets replayed during this renegotiation as if it had been authenticated by the client certificate, but it has not. The discoverer of the problem describes this as an "authentication gap".

According to the report, an attack could unfold as follows:

An attacker cuts into the connection between the client and server and establishes an HTTPS connection with the server. He starts out by temporarily holding the connection to the client in an incomplete state. He sends the server an HTTPS request for a secure area – the server then renegotiates a completely new connection and requests the client certificate. The attacker forwards all subsequent packets between the client and server unchanged. Finally, the attacker's HTTP request – e.g. a POST request for a protected form – is executed as if it came from the client.

The problem has been shown to exist in the latest versions of the Microsoft IIS and Apache Foundation httpd web servers, and OpenSSL are also affected. A patch has been developed by Ben Laurie, but it merely stops renegotiation and does not resolve the actual problem. A long-term solution is under discussion. One possibility would be to issue client certificates earlier, before a specific URL is requested. The IETF's TLS Channel Bindings Working Group is also reported to be working on a draft, which may already contain a solution.

Dịch tài liệu: Lê Trung Nghĩa

letrungnghia.foss@gmail.com