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

Vulnerabilityin 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ênInternet ngày: 05/11/2009

Lờingười dịch: Lỗi trong giao thức SSL/TLS có thể gây ảnhhưởng cho cả máy chủ web IIS của Microsoft và các máychủ 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 dungvà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ứckhá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 websitetrong 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ạolạ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 truycậ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ậpthì điều đó là trường hợp này, và nó bắt đầu mộtsự thảo luận lại để có được xác thực máy trạmphù hợp. Yêu cầu ban đầu được thực hiện lại tronglúc thảo luận lại này dường như náo đã được xácthực bởi sự xác thực của máy trạm, nhưng nó lạikhô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ộtcuộc tấn công có thể mở ra như sau:

Một kẻ tấn côngcắt kết nối giữa máy chủ và máy trạm và thiết lậpmộ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ạngkhông hoàn thiện. Kẻ này gửi cho máy chủ một yêu cầuHTTPS cho một vùng an ninh - máy chủ sau đó thảo luận lạimột kết nối mới hoàn toàn và yêu cầu xác thực máytrạm. Kẻ này chuyển tiếp tất cả các gói sau đó giữamá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 POSTcho 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ênbản mới nhất của IIS của Microsoft và các máy chủ webhttpd 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ảiquyết vấn đề một cách thực sự. Một giải phápdà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áchnhiệm cho Kênh TLS của IETF cũng được cho là sẽ làmviệc về một dự thảo, mà nó có thể đã có chứa mộtgiải pháp.

Accordingto reports, vulnerabilities in the SSL/TLS protocol can be exploitedby attackers to in-sert content into secure connections. If this iscorrect, it would affect HTTPS and all other protocols which use TLSfor security, including IMAP. The precise effects of the problem arenot discussed in the reports. It would, however, appear to bepossible to manipulate HTML content f-rom websites during datatransfer and, for example, inject malicious code.

Thecrux of the problem is, rather than a flawed implementation, a designflaw in the TLS protocol when renegotiating parameters for anexisting TLS connection. This occurs when, for example, a clientwants to access a secure area on a web server which requires therequesting client certificates. When the server establishes that isthe case, it begins a renegotiation to obtain the appropriate clientcertificate. The original request gets replayed during thisrenegotiation as if it had been authenticated by the clientcertificate, but it has not. The discoverer of the problem describesthis as an "authentication gap".

Accordingto the report, an attack could unfold as follows:

Anattacker cuts into the connection between the client and server andestablishes an HTTPS connection with the server. He starts out bytemporarily holding the connection to the client in an incompletestate. He sends the server an HTTPS request for a secure area – theserver then renegotiates a completely new connection and requests theclient certificate. The attacker forwards all subsequent packetsbetween the client and server unchanged. Finally, the attacker's HTTPrequest – e.g. a POST request for a protected form – is executedas if it came f-rom the client.

Theproblem has been shown to exist in the latest versions of theMicrosoft IIS and Apache Foundation httpd web servers, and OpenSSLare also affected. A patch has been developed by Ben Laurie, but itmerely stops renegotiation and does not resolve the actual problem. Along-term solution is under discussion. One possibility would be toissue client certificates earlier, before a specific URL isrequested. The IETF's TLS Channel Bindings Working Group is alsoreported to be working on a draft, which may already contain asolution.

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

letrungnghia.foss@gmail.com