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
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 charged 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, whereas 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), whereas 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 from 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 create 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 alternatives 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
