The SSL 3.0+ and TLS 1.0+ protocols are vulnerable to a set of related attacks which allow a man-in-the-middle (MITM) operating at or below the TCP layer to inject a chosen plaintext prefix into the encrypted data stream, often without detection by either end of the connection. This is possible because an “authentication gap” exists during the renegotiation process at which the MitM may splice together disparate TLS connections in a completely standards-compliant way. This represents a serious security defect for many or all protocols which run on top of TLS, including HTTPS.
 

* Ngân hàng A có cung cấp dịch vụ Internet Banking ở địa chỉ https://www.ebank.com. Máy chủ của của họ chạy phần mềm có lỗ hổng mà chúng ta đang bàn ở đây. Chúng ta gọi máy chủ này là server.

* Để tăng cường an ninh, ngân hàng A yêu cầu khi khách hàng (giờ cứ gọi là client) sử dụng các tính năng có liên quan đến giao dịch tài chính nằm trong khu vực https://www.ebank.com/account/, thì (browser của) họ phải có cài đặt client certificate cho ngân hàng A cung cấp. Lưu ý là nhiều ngân hàng ở VN thực hiện cái này lắm nha.

* Ngoài ra ngân hàng A còn hỗ trợ khách hàng truy cập bằng (Safari trên) iPhone, lúc đó khách hàng sẽ được chuyển đến https://www.ebank.com/iphone/. Do iPhone có processor yếu, nên ngân hàng A cấu hình máy chủ web của họ để sử dụng một bộ ciphersuite yếu hơn bộ ciphersuite mà họ sử dụng cho các khách hàng thông thường. Cái này trong thực tế cũng có nhiều công ty triển khai.

 

...
POST /account/transfer?amount=1000&receiver=attacker HTTP/1.1\r\n
...

Ý tưởng thực hiện tấn công rất giống với hướng 2, chỉ khác nhau ở bước số 2, attacker sẽ không gửi GET /iphone/login nữa mà gửi trực tiếp luôn request của hắn, kèm theo một cái "X-ignore-this" header.
 

1) việc gắn 2 messages không phải do attacker làm, mà là do server làm.
 

Scenario: Client-initiated renegotiation
TLS equally allows the client side of the connection to initiate a renegotiation. This case
is perhaps more attractive to the attacker because he does not need to elicit a Hello
Request from the server, so no particular server-side configuration is required for this
attack to succeed.
In the HTTPS domain, a practical attack involves the MITM splicing an initial request
with an un-terminated HTTP “ignore” header onto the beginning of the client's intended
request, again stealing whatever authentication or authorization information provided.
Note that this does not require pipelining or HTTP keep-alive. In all other respects, the
server sees the same sort of request buffer as above.
 

- client phải authenticate server trước khi send certificate cho server ( cái này chưa hiểu lắm anh mrro có thể giải thích không ? )
 

If necessary, SSL_read() will negotiate a TLS/SSL session, if not already explicitly performed by SSL_connect(3) or SSL_accept(3). If the peer requests a re-negotiation, it will be performed transparently during the SSL_read() operation. The behaviour of SSL_read() depends on the underlying BIO.
 

Note that higher layers should not be overly reliant on whether TLS
always negotiates the strongest possible connection between two
peers. There are a number of ways in which a man-in-the-middle
attacker can attempt to make two entities drop down to the least
secure method they support. The protocol has been designed to
minimize this risk, but there are still attacks available: for
example, an attacker could block access to the port a secure service
runs on, or attempt to get the peers to negotiate an unauthenticated
connection. The fundamental rule is that higher levels must be
cognizant of what their security requirements are and never transmit
information over a channel less secure than what they require. The
TLS protocol is secure in that any cipher suite offers its promised
level of security: if you negotiate 3DES with a 1024-bit RSA key
exchange with a host whose certificate you have verified, you can
expect to be that secure. 

RFC2595 – Using TLS with IMAP, POP3 and ACAP

A TLS negotiation begins immediately after the CRLF at the end of the tagged OK response from the server. Once a client issues a STARTTLS command, it MUST NOT issue further commands until a server response is seen and the TLS negotiation is complete.

The STARTTLS command is only valid in non-authenticated state. The server remains in non-authenticated state, even if client credentials are supplied during the TLS negotiation. The SASL [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS client credentials are successfully exchanged, but servers supporting the STARTTLS command are not required to support the EXTERNAL mechanism.

Once TLS has been started, the client MUST discard cached information about server capabilities and SHOULD re-issue the CAPABILITY command. This is necessary to protect against man-in-the-middle attacks which alter the capabilities list prior to STARTTLS. The server MAY advertise different capabilities after STARTTLS.

http://www.faqs.org/rfcs/rfc2595.html
 

Về mặt nguyên tắc thì toàn bộ communication phải được bound với credentials, bao gồm cả requests lẫn replies
 

sorry em không hiểu ý anh PD, em thấy đoạn anh quote chỉ ra rằng người thiết kế protocol đã rất cẩn thận lưu ý developer khi xử dụng chung với IMAP, POP3 and ACAP, tuy vậy những cảnh báo đó không có trong bản RFC với HTTP (?!? http://tools.ietf.org/html/rfc2818)

MitM dù có thể có cer của client và auth với server, nhưng nếu client và server trong TLS state (đã negotiate và trao đổi key xong) thì attacker cũng không thể fake client dc vì không có correct key.

Em cũngg cùng chung suy nghĩ này với StarGhost

StarGhost wrote:

Về mặt nguyên tắc thì toàn bộ communication phải được bound với credentials, bao gồm cả requests lẫn replies
 

 

Vấn đề được đặt ra là: ở điều kiện thế nào thì MitM có thể đắc lợi được và mitigate những tấn công ở dạng này phải chăng chỉ trông cậy hoàn toàn vào SSL/TLS và những ứng dụng của các protocol khác ở tầng cao hơn?  

Một phát hiện hết sức thú vị. Thú vị ở chỗ bao nhiêu người, bao nhiêu chuyên gia, bao nhiêu năm qua dòm vô TLS/SSL mà không thấy được lỗ hổng có vẻ như rất hiển nhiên mà các tác giả ở trên phát hiện. Có lẽ nguyên nhân nhiều người dòm nhưng không thấy là vì họ chỉ dòm TLS/SSL khi nó đứng một mình, mà không nhìn vào bức tranh lớn OSI, trong đó TLS/SSL chỉ là một layer. Chuyện gì sẽ xảy ra nếu TLS/SSL không hiểu rõ cơ chế hoạt động của các protocol bên trên nó, như HTTP, SMTP hay POP3? Nói cách khác, chuyện gì sẽ xảy ra nếu các protocol ở mức Application không hiểu rõ cơ chế vận hành của TLS/SSL để sử dụng cho đúng cách? Đó là lúc lỗ hổng xuất hiện.
 

bài viết này cách đây gần 10 năm mà bây giờ em mới mò ra thật đáng xấu hổ.
các anh hay thật