creare una fondazione per una CA libera?
che costa non poco...,
Internet architects propose encrypting all the world’s Web traffic
Next-gen HTTP calls for default crypto to stop spying by spooks and criminals.
Todor Petkov
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.
Promoted Comments
The UglyArs Praetorian
jump to post
We already know state actors (and some criminal/hacker groups) pervert SSL/TLS
certificate authorities. I think it's great to encrypt more traffic, but as the
end of the article notes, this is all somewhat pointless to stop government
spying unless the fundamental flaws in the CA system are addressed.
413 posts | registered Jun 11, 2007
daggarArs Scholae Palatinae
jump to post
Anything that proposes more security but still relies on centralized
certificate authorities is a joke. After the revelations that have come out
about the extent of the NSA's activity, the smart money is betting that at
least some of the root CA's have been subverted, whether through cooperation or
external compromise.
826 posts | registered Sep 17, 2010
DilbertArs Legatus Legionis
jump to post
Quote:
Also, hi Ars. As security conscious as your articles are, why don't you support
https yet? Get on that shit. What news stories a person reads can tell a lot
about a person, like for example to identify if his or her love for big brother
is wavering.
Become a subscriber and you'll be able to access Ars over HTTPS. It costs more
to serve an SSL page than it does to serve a plain text one.
16969 posts | registered Mar 15, 2002
Wes FelterArs Scholae Palatinae
jump to post
The IETF's deliberate compartmentalization into working groups seems to be
hindering them from discussing or solving the big picture. People in HTTPbis
keep saying "fixing CAs is not our problem; take it to TLS WG" and I can only
imagine that similar buck-passing is going on over in TLS.
923 posts | registered Apr 23, 2008
PhilipKGlassSmack-Fu Master, in training
jump to post
DNick wrote:
Big bro already knows about my disdain from my perfectly candid comments here
and all over the Internet. Having an encrypted connection between Ars and
snarky me doesn't protect me in any way, since the NSA can read my comments
with their own connection, encrypted or not.
I don't think there's a need to protect one's self against things we are not
trying to keep private in the first place. It's more like e-mails, medical
sites, banking and investments - but all of that said, I still think encrypting
all data by default is a great idea.
An attacker that can see the body of your comment plus metadata like IP address
and headers knows your approximate geographic region, OS, and browser as well
as the content of your post. With dissection of unencrypted comments to Ars
it's not just "DNick dislikes big brother," it's "DNick dislikes big brother,
and lives in Country X so we know which partner countries can legally target
him, and uses Platform Y so we know which software exploits are likely to work
if we need to subvert his machine." I don't think it's likely that any of us
will be targeted simply for griping in public forum comments, but getting the
user name, comment, and metadata together provides more leverage for an
attacker than just getting the user name and comment by reading the site.
3 posts | registered Nov 14, 2013
Dan Goodin / Dan is the IT Security Editor at Ars Technica, which he joined in
2012 after working for The Register, the Associated Press, Bloomberg News, and
other publications.
← Older Story
Newer Story →
_______________________________________________
Open
https://lists.partito-pirata.it/cgi-bin/mailman/listinfo/open
