* 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
...

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.  

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  

:D 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