Các kiến trúc sư Internet đề xuất việc mã hóa tất cả giao thông Web của thế giới

Internet architects propose encrypting all the world’s Web traffic

Kêu gọi HTTP thế hệ tiếp sau thành mật mã mặc định để dừng việc gián điệp của ma quỷ và bọn tội phạm

Next-gen HTTP calls for default crypto to stop spying by spooks and criminals.

by Dan Goodin - Nov 15 2013, 2:40am ICT

Theo: http://arstechnica.com/security/2013/11/encrypt-all-the-worlds-web-traffic-internet-architects-propose/

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

Lời người dịch: Việc mã hóa Internet đã trở thành vấn đề cấp bách sau những tiết lộ của Edward Snowden về sự giám sát ồ ạt của Cơ quan An ninh Quốc gia Mỹ (NSA). Nhiều chuyên gia an ninh nghĩ tới khả năng mã hóa toàn bộ giao thông Internet thế giới. Tuy nhiên, với hệ thống các giao thức hiện đang được sử dụng như TLS và SSL cùng số lượng các cơ quan chứng thực trên toàn thế giới lên tới con số 500, thì rất nhiều khó khăn phát sinh. “Không may, các đề xuất đang đi qua một tình thế quan trọng trong tranh luận đối với mã hóa Web, có liên quan tới tính trực quan của các giao thức SSL và TLS hiện hành đang chống trụ cho toàn bộ giao thông HTTPS. Với hơn 500 cơ quan chứng thực CA nằm khắp thế giới được các trình duyệt chính thừa nhận, tất cả điều sẽ thấy là sự tổn thương của một trong số chúng làm cho toàn bộ hệ thống sập (dù chứng thực làm móng trong một số trường hợp giúp có sự thiệt hại). Không có gì trong bức thư Nottingham chỉ ra rằng điểm thất bại duy nhất này sẽ được giải quyết. Hệ thống HTTPS hiện hành có những tác động nghiêm trọng về tính riêng tư đối với những người sử dụng đầu cuối, vì các cơ quan chứng thực CA có thể lưu ý số lượng khổng lồ các yêu cầu đối với các website được bảo vệ bằng SSA và ánh xạ chúng tới các địa chỉ IP riêng rẽ. Điều này cũng không được giải quyết”. Xem thêm: 'Chương trình gián điệp PRISM trên không gian mạng'.

Phần trăm lớn hơn nhiều giao thông Web của thế giới sẽ được mã hóa theo khuyến cáo gần như cuối cùng để duyệt lại giao thức truyền siêu dữ văn bản HTTP phục vụ như là nền tảng cho tất cả các giao tiếp truyền thông giữa các website và người sử dụng đầu cuối.

Đề xuất đó, được nêu trong một bức thư được xuất bản hôm thứ tư từ một quan chức với Đội Đặc nhiệm Thiết kế Internet - IETF (Internet Engineering Task Force), tới sau khi các tài liệu bị rò rỉ từ cựu nhà thầu của Cơ quan An ninh Quốc gia Mỹ (NSA) Edward Snowden đã dấy lên cao độ những lo lắng về sự giám sát các giao tiếp truyền thông Internet của chính phủ. Bất chấp các lo lắng đó, các website do Yahoo, chính phủ liên bang, vận hành, site có bài viết này, và các site khác tiếp tục xuất bản đa số các trang của họ trong một định dạng “văn bản thô” mà có thể đọc được đối với các gián điệp của chính phủ hoặc bất kỳ ai khác mà có sự truy cập tới mạng mà giao thông đó đi ngang qua. Tuần trước, nhà mật mã học và chuyên gia an ninh Bruce Schneier đã thúc giục mọi người “làm cho sự giám sát đắt giá một lần nữa” bằng việc mã hóa càng nhiều dữ liệu Internet càng tốt.

Nhóm làm việc HTTPbis (HTTPbis Working Group), cơ quan trực thuộc IETF có trách nhiệm với việc thiết kế đặc tả thế hệ tiếp sau HTTP2.0, đang đề xuất rằng mã hóa là cách mặc định để dữ liệu được truyền qua “Internet mở”. Đang gia tăng một số nhóm tham gia trong quá trình làm tiêu chuẩn - đặc biệt những người phát triển các trình duyệt web - hỗ trợ cho động thái này, dù là điển hình trong những suy xét thận trọng, có tranh luận về làm thế nào để triển khai tốt nhất những thay đổi.

“Dường như có sự đồng thuận mạnh mẽ để gia tăng sử dụng mã hóa trên Web, nhưng có ít sự đồng thuận về cách để đi tới điều này”, Mark Nottingham, chủ tịch của nhóm làm việc HTTPbis, đã viết trong một bức thư hôm thứ tư. (HTTPbis dịch thô sang “HTTP một lần nữa”).

Ông đi tới đưa ra 3 đề xuất triển khai và mô tả các điểm mạnh và yếu của chúng:

A. Mã hóa cơ hội cho http:// các URI mà không có xác thực máy chủ - gọi là “TLS thoải mái” như cho mã hóa http2 dự thảo nottingham.

B. Mã hóa cơ hội cho các URI http:// với xác thực máy chủ - cơ chế y hệt, nhưng không “thoải mái”, cùng với một số dạng bảo vệ thấp.

C. HTTP/2 sẽ chỉ được sử dụng với https:// URI trên Internet “mở”. Các http:// URI có thể tiếp tục sử dụng HTTP/1 (và tất nhiên nó có thể vẫn có khả năng cho các máy trạm HTTP/1 cũ vẫn tương hợp được với các https:// URI).

Trong thảo luận phụ, dường như có thỏa thuận rằng (C) là ưu tiên hơn (B), vì nó là thẳng tiến hơn; không có cơ chế mới nào cần phải được chỉ định, và HSTS có thể được sử dụng cho sự bảo vệ thấp hơn.

(C) cũng có ưu điểm này hơn (A) và hơn nữa đưa ra sự bảo vệ mạnh hơn đối với các cuộc tấn công tích cực.

Những phản đối mạnh mẽ nhất chống lại (A) dường như là về việc tạo ra sự lộn xộn về an ninh và việc không khuyến khích sử dụng TLS “đầy đủ”, trong khi những phản đối chống lại (C) từng là về việc hạn chế triển khai an ninh tốt hơn.

Các nhà quan sát tỉ mỉ đã lưu ý rằng chúng ta có thể triển khai (C) và phán xét sự áp dụng giao thức mới, sau đó bổ sung thêm (A) nếu thấy cần thiết. Ngược lại là không nhất thiết đúng.

Hơn nữa, trong các thảo luận với các nhà cung cấp trình duyệt (những người từng trong đám bảo vệ mạnh mẽ nhất sử dụng mã hóa nhiều hơn), dường như có sự hỗ trợ tốt cho (C), trong khi vẫn có một lượng khá nghi ngờ/không đồng ý về (A).

Ưu, nhược điểm và củ cà rốt

Như Nottingham đã thừa nhận, có những ưu và nhược điểm chính cho từng lựa chọn. Đề xuất A có thể dễ dàng hơn cho các website để triển khai vì nó sẽ không đòi hỏi chúng xác thực các máy chủ của chúng bằng việc sử dụng một chứng thực số mà được tất cả các trình duyệt chính thừa nhận. Sự thoái mái này đối với các yêu cầu HTTPS hiện hành có thể loại bỏ một rào cản mà dừng nhiều website khỏi việc mà hóa giao thông bây giờ, nhưng nó cũng kèm theo chi phí. Sự thiếu xác thực có thẻ làm cho nó tầm thường đối với một người trong Internet cà phê hoặc gián điệp theo dõi các trục xương sống Internet để tạo ra một chứng thực số rởm mà giả mạo các website bằng việc sử dụng dạng an ninh lớp vận tải thoải mái này (TLS). Rủi ro đó gợi lên câu hỏi liệu biện pháp làm suy yếu có đáng tranh cãi để triển khai hay không.

Đề xuất B, ngược lại, có thể làm khó hơn nhiều cho các kẻ tấn công, vì giao thông HTTP2.0 mặc định có thể vừa được mã hóa vừa được xác thực. Nhưng chi phí gia tăng và nỗ lực đòi hỏi hàng triệu website có thể làm giảm sự áp dụng của đặc tả mới này, bổ sung thêm vào sự mã hóa chào các cải tiến như nén đầu đề gia tăng và dồn đa kênh kết nối không đồng bộ.

Đề xuất C dường như để giải quyết căng thẳng giữa 2 lựa chọn khác bằng việc chuyển vào một hướng khác đồng thời - đó là, bằng việc triển khai HTTP 2.0 chỉ trong giao thông HTTPS đẩy đủ. Tiếp cận này cố gắng sử dụng nhiều cải tiến của tiêu chuẩn mới như một củ cà rốt mà trao cho các website một sự động viên để bảo vệ giao thông của họ với mã hóa HTTPS truyền thống.

Các lựa chọn mà nhóm làm việc đang xem xét làm một công việc tốt về ánh xạ tranh luận hiện hành đối với sự mã hóa dựa vào Web. Một lý do chung là nhiều site hơn có thể và sẽ mã hóa tất cả hoặc ít nhất hầu hết các giao thông của chúng. Thậm chí tốt hơn là khi các site cung cấp sự mã hóa này trong khi cùng lúc đưa ra các đảm bảo mật mã mạnh mà việc đặt chỗ máy chủ cho website là một chỗ được vận hành bởi nắm giữ tên miền được liệt kê trong thanh địa chỉ - hơn là bằng một kẻ tấn công mà đinh can thiệp với sự kết nối.

Không may, các đề xuất đang đi qua một tình thế quan trọng trong tranh luận đối với mã hóa Web, có liên quan tới tính trực quan của các giao thức SSL và TLS hiện hành đang chống trụ cho toàn bộ giao thông HTTPS. Với hơn 500 cơ quan chứng thực CA nằm khắp thế giới được các trình duyệt chính thừa nhận, tất cả điều sẽ thấy là sự tổn thương của một trong số chúng làm cho toàn bộ hệ thống sập (dù chứng thực làm móng trong một số trường hợp giúp có sự thiệt hại). Không có gì trong bức thư Nottingham chỉ ra rằng điểm thất bại duy nhất này sẽ được giải quyết. Hệ thống HTTPS hiện hành có những tác động nghiêm trọng về tính riêng tư đối với những người sử dụng đầu cuối, vì các cơ quan chứng thực CA có thể lưu ý số lượng khổng lồ các yêu cầu đối với các website được bảo vệ bằng SSA và ánh xạ chúng tới các địa chỉ IP riêng rẽ. Điều này cũng không được giải quyết.

Không may là bức thư đó đã không đề xuất các lựa chọn thay thế cho hệ thống TLS phần lớn bị què, như một ai đó đã nêu Xác nhận Sự tin cậy cho các Khóa Chứng thực (Trust Assertions for Certificate Keys), nó từng được các nhà nghiên cứu Moxie Marlinspike và Trevor Perrin hiểu. Một lần nữa, như những điều có bây giờ, các kỹ sư trong Nhóm làm việc HTTPbis có khả năng đang quản lý càng nhiều xung đột có thể càng tốt. Việc bổ sung một cách thức mới hoàn toàn để mã hóa giao thông Web vào một danh sách những cân nhắc đã nằm bò rồi có lẽ có thể chứng minh sẽ là quá nhiều.

A vastly larger percentage of the world's Web traffic will be encrypted under a near-final recommendation to revise the Hypertext Transfer Protocol (HTTP) that serves as the foundation for all communications between websites and end users.

The proposal, announced in a letter published Wednesday by an official with the Internet Engineering Task Force (IETF), comes after documents leaked by former National Security Agency contractor Edward Snowden heightened concerns about government surveillance of Internet communications. Despite those concerns, websites operated by Yahoo, the federal government, the site running this article, and others continue to publish the majority of their pages in a "plaintext" format that can be read by government spies or anyone else who has access to the network the traffic passes over. Last week, cryptographer and security expert Bruce Schneier urged people to "make surveillance expensive again" by encrypting as much Internet data as possible.

The HTTPbis Working Group, the IETF body c-harged with designing the next-generation HTTP 2.0 specification, is proposing that encryption be the default way data is transferred over the "open Internet." A growing number of groups participating in the standards-making process—particularly those who develop Web browsers—support the move, although as is typical in technical deliberations, there's debate about how best to implement the changes.

"There seems to be strong consensus to increase the use of encryption on the Web, but there is less agreement about how to go about this," Mark Nottingham, chair of the HTTPbis working group, wrote in Wednesday's letter. (HTTPbis roughly translates to "HTTP again.")

He went on to lay out three implementation proposals and describe their pros and cons:

A. Opportunistic encryption for http:// URIs without server authentication—aka "TLS Relaxed" as per draft-nottingham-http2-encryption.

B. Opportunistic encryption for http:// URIs with server authentication—the same mechanism, but not "relaxed," along with some form of downgrade protection.

C. HTTP/2 to only be used with https:// URIs on the "open" Internet. http:// URIs would continue to use HTTP/1 (and of course it would still be possible for older HTTP/1 clients to still interoperate with https:// URIs).

In subsequent discussion, there seems to be agreement that (C) is preferable to (B), since it is more straightforward; no new mechanism needs to be specified, and HSTS can be used for downgrade protection.

(C) also has this advantage over (A) and furthermore provides stronger protection against active attacks.

The strongest objections against (A) seemed to be about creating confusion about security and discouraging use of "full" TLS, whe-reas those against (C) were about limiting deployment of better security.

Keen observers have noted that we can deploy (C) and judge adoption of the new protocol, later adding (A) if necessary. The reverse is not necessarily true.

Furthermore, in discussions with browser vendors (who have been among those most strongly advocating more use of encryption), there seems to be good support for (C), whe-reas there's still a fair amount of doubt/disagreement regarding (A).

Pros, cons, and carrots

As Nottingham acknowledged, there are major advantages and disadvantages for each option. Proposal A would be easier for websites to implement because it wouldn't require them to authenticate their servers using a digital certificate that is recognized by all the major browsers. This relaxation of current HTTPS requirements would eliminate a hurdle that stops many websites f-rom encrypting traffic now, but it also comes at a cost. The lack of authentication could make it trivial for the person at an Internet cafe or the spy monitoring Internet backbones to cre-ate a fraudulent digital certificate that impersonates websites using this form of relaxed transport layer security (TLS). That risk calls into question whether the weakened measure is worth the hassle of implementing.

Proposal B, by contrast, would make it much harder for attackers, since HTTP 2.0 traffic by default would be both encrypted and authenticated. But the increased cost and effort required by millions of websites may stymie the adoption of the new specification, which in addition to encryption offers improvements such as increased header compression and asynchronous connection multiplexing.

Proposal C seems to resolve the tension between the other two options by moving in a different direction altogether—that is, by implementing HTTP 2.0 only in full-blown HTTPS traffic. This approach attempts to use the many improvements of the new standard as a carrot that gives websites an incentive to protect their traffic with traditional HTTPS encryption.

The options that the working group is considering do a fair job of mapping the current debate over Web-based encryption. A common argument is that more sites can and should encrypt all or at least most of their traffic. Even better is when sites provide this encryption while at the same time providing strong cryptographic assurances that the server hosting the website is the one operated by the domain-name holder listed in the address bar—rather than by an attacker who is tampering with the connection.

Unfortunately, the proposals are passing over an important position in the debate over Web encryption, involving the viability of the current TLS and secure sockets layer (SSL) protocols that underpin all HTTPS traffic. With more than 500 certificate authorities located all over the world recognized by major browsers, all it takes is the compromise of one of them for the entire system to fail (although certificate pinning in some cases helps contain the damage). There's nothing in Nottingham's letter indicating that this single point of failure will be addressed. The current HTTPS system has serious privacy implications for end users, since certificate authorities can log huge numbers of requests for SSL-protected websites and map them to individual IP addresses. This is also unaddressed.

It's unfortunate that the letter didn't propose al-ternatives to the largely broken TLS system, such as the one dubbed Trust Assertions for Certificate Keys, which was conceived by researchers Moxie Marlinspike and Trevor Perrin. Then again, as things are now, the engineers in the HTTPbis Working Group are likely managing as much controversy as they can. Adding an entirely new way to encrypt Web traffic to an already sprawling list of considerations would probably prove to be too much.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com