Thứ Bảy, 30 tháng 11, 2013

TPP, ACTA, bằng sáng chế phần mềm và hơn thế nữa

Danh sách này sẽ còn cập nhật thông tin về các bài viết theo chủ đề bằng sáng chế phần mềm theo trật tự thời gian, tin mới nhất lên đầu. Các bài có dấu * là các bài không nên bỏ qua.
Blogger: Lê Trung Nghĩa

Thứ Năm, 28 tháng 11, 2013

Mã hóa dữ liệu là cách duy nhất ẩn dấu được khỏi NSA và các cơ quan an ninh - các chuyên gia nói


Encryption of data is the only way to hide from NSA, security agencies - experts
13 November 2013, 10:09
Bài được đưa lên Internet ngày: 13/11/2013
Encryption of data is the only way to hide from NSA, security agencies - experts
Photo: niallkennedy/flickr.com
Lời người dịch: Để đảm bảo cho dữ liệu của bạn không bị ai chọc ngoáy, điều quan trọng nhất là mã hóa chúng ngay trên máy của chính bạn trước khi bạn định chuyển nó đi bất kỳ đâu. Hãy nhớ kỹ điều này!!! “Khi sử dụng các mạng wifi mở, phải nhận thức được rằng có ai khác có thể truy cập được các tệp của bạn, dù nó là các tội phạm gián điệp hay thông thường đang tìm kiếm thông tin ngân hàng”, nghĩa là khi sử dụng wifi mở, luôn phải nghĩ có ai đó đang theo dõi bạn!!! Bài viết rất bổ ích cho người sử dụng đầu cuối. Bạn hãy tự đọc hết và rút ra cho mình kết luận cần thiết. Xem thêm: 'Chương trình gián điệp PRISM trên không gian mạng'.
Mỗi tiết lộ về các hoạt động gián điệp của Cơ quan An ninh Quốc gia Mỹ (NSA) chỉ làm rõ hơn rằng mọi người cần mã hóa các dữ liệu trực tuyến của họ nếu họ muốn thoát khỏi các con mắt rình mò. Điểm đó từng chỉ được làm cho rõ hơn bằng báo cáo gần đây trên tờ Washington Post mà đã nêu cơ quan gián điệp từng thu thập các dữ liệu từ Google và Yahoo.
“Nếu bạn thực hiện một điểm cho việc mã hóa các thư điện tử, thì bạn sẽ làm cho nó khó hơn đáng kể cho các cơ quan an ninh”, Stefan Katzenbeisser nói cho Trung tâm Nghiên cứu An ninh Tiên tiến - CASED (Center for Advanced Security Research) ở Đại học Kỹ thuật Darmstadt của Đức.
Mã hóa chỉ thực sự làm việc nếu cả người viết và người nhận sử dụng cùng các phương pháp bí mật như nhau. Mã hóa phù hợp cũng dựa vào thứ gì đó được gọi là một chứng chỉ, nó có thể là khó cho một người bình thường để truy cập.
“Hạ tầng thực sự thiếu đối với thị trường số đông”, Katzenbeisser nêu. Nó không giúp được nhiều khi các chương trình không đưa ra một lựa chọn mã hóa. Những người thực sự có quan tâm trong an ninh trước hết phải có một trình cài cắm.
Các thư điện tử cũng không chỉ là dạng tệp bị các cuộc tấn công của NSA làm ảnh hưởng.
Các trung tâm lưu trữ đám mây là mục tiêu khác. Chúng có thể được mã hóa với các hệ thống như Truecrypt, Cloudfogger hoặc Boxcryptor, ví dụ thế. Nhưng bằng việc làm như thế có thể làm cho khó khăn hơn để tải lên và tải xuống các tệp. Tuy nhiên, việc duy trì các chương trình là đủ dễ dàng cho hầu hết những người mới làm quen.
Ngoài sự mã hóa, những người sử dụng web nên luôn chắc chắn rằng các kết nối là có an ninh. Điều đó có nghĩa là việc sử dụng những điều như các giao thức SSL, nó đưa ra tính riêng tư bổ sung trong các trình duyệt và có thể được nhận ra bằng các ký tự “https” ở đầu của một địa chỉ web và một biểu tượng khóa.
Khi sử dụng các mạng wifi mở, phải nhận thức được rằng có ai khác có thể truy cập được các tệp của bạn, dù nó là các tội phạm gián điệp hay thông thường đang tìm kiếm thông tin ngân hàng.
Lựa chọn khác là chuyển sang một nhà cung cấp Internet với các máy chủ không đặt ở Mỹ.
“Rõ ràng dễ dàng hơn cho các cơ quan của Mỹ để truy cập các dịch vụ Mỹ”, Katzenbeisser nói. Nhưng thông tin là không nhất thiết an toàn ở những nơi khác. “Tôi không bao giờ biết liệu có thể có gián điệp của ai đó ở đó hay không, như, ví dụ, cơ quan an ninh địa phương”.
Không có đảm bảo nào rằng các dịch vụ tại các nước khác không có các vấn đề về an ninh của riêng nó.
Tạp chí Đức đã nêu một kiểm thử các dịch vụ thư điện tử Đức và đã phát hiện rằng hầu hết đã không cam kết là một hệ thống đảm bảo rằng các tệp được mã hóa trong quá khứ giữ được sự bảo vệ trong tất cả các tình huống … như khi bị một cơ quan chính phủ lấy mất.
Voice of Russia, dpa
Every revelation about the spying activities of the US National Security Agency (NSA) only makes it clearer that people need to encrypt their online data if they want to keep it away from prying eyes.
That point was only made clearer by a recent Washington Post report that alleged the spy agency was trawling for data from Google and Yahoo.
"If you make a point of encrypting emails, you make it significantly more difficult for the security agencies," says Stefan Katzenbeisser of the Center for Advanced Security Research (CASED) at the Darmstadt Technical University in Germany.
Encryption only really works if both the writer and recipient use the same secrecy methods. Proper encryption also relies on something called a certificate, which can be hard for a normal person to access.
"The infrastructure is really lacking for the mass market," complains Katzenbeisser. It doesn't help that a lot of email programmes don't offer an encryption option. Those who are really interested in security first have to get a plug-in.
Nor are emails the only kind of files affected by NSA attacks.
Cloud storage centres are another target. These can be encrypted with systems like Truecrypt, Cloudfogger or Boxcryptor, for example. But doing so can make it more difficult to upload and download files. Maintaining the programmes, however, is easy enough for most novices.
Aside from encryption, web users should always make sure that connections are secure. That means using things like SSL protocols, which provide added privacy on browsers and can be recognized by the letters "https" at the beginning of a web address and a padlock icon.
The real trick is to never let down one's guard.
When using open wi-fi networks, be aware that anyone else can access your files, whether it be spies or regular criminals looking for banking information.
Another option is to switch to an internet provider with no US-based servers.
"It's obviously easier for US agencies to access US services," says Katzenbeisser. But information is not necessarily safe elsewhere. "I never know if maybe someone's spying there, like, perhaps, the local security agency."
Nor are there guarantees that services in other countries don't have their own security problems.
German magazine ran a test of German email services and discovered that most had failed to engage a system that ensured that files encrypted in the past kept that protection in all circumstances .... like when seized by a government agency.
Voice of Russia, dpa
Dịch: Lê Trung Nghĩa

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