HTTP 2.0 và tương lai bảo mật Internet

Lộ trình của HTTP 2.0

Sau 15 năm dài, tổ chức Internet Engineering Task Force (IETF) đã có kế hoạch nâng cấp giao thức HTTP cho các trung tâm Internet. IETF dự định hoàn thiện các quy định mới cho hệ thống truyền dữ liệu vào cuối năm 2014.

Ngày càng nhiều người dùng bị nhầm lẫn bởi cái được gọi là đường truyền băng thông rộng tốc độ cao, giá đắt đỏ với sự hứa hẹn của các nhà cung cấp mạng là khả năng tải dữ liệu lên đến 50Mb hoặc cao hơn nữa. Nhưng tất cả đều làm người dùng vỡ mộng bởi trong thực tế, các website không có khả năng cho phép tải bất cứ thứ gì nhanh hơn so với kết nối DSL cũ (sơ đồ minh họa). Thiết bị phần cứng được nâng cấp, ứng dụng nhiều công nghệ mới nhưng cũng sẽ không làm cho trang web nhanh hơn đáng kể bởi giao thức Internet lỗi thời.
Việc này khiến giao tiếp giữa các trình duyệt và máy chủ bị cản trở và người dùng không được đảm bảo tốc độ lướt web tốt nhất. Lý do là giao thức Internet hiện tại chỉ sử dụng tốt nhất khi tải các trang HTML đơn giản hoặc một số đồ họa cơ bản. Ngày nay, giao thức Internet cũ này đã quá bình thường khi mà phải xử lý hàng trăm dòng mã kịch bản trên và hàng loạt truy xuất từ nhiều nguồn khác nhau trên các trang web. Ngoài ra khối lượng lớn dữ liệu tương tác liên tục giữa người dùng và máy chủ website hay việc mã hóa tự động để bảo vệ sự riêng tư đang đòi hỏi khả năng xử lý mạnh mẽ hơn.

Ví dụ cụ thể nhất là HTTP, giao thức ứng dụng này là trung tâm điều hòa truyền thông giữa các trình duyệt và máy chủ. Phiên bản mới nhất 1.1 được giới thiệu vào đầu năm 1999 và không thường xuyên được tối ưu hóa, nâng cấp hay cải thiện. Những hạn chế của nó đã thể hiện rõ trong bảng so sánh dưới đây. Đó là lý do tại sao các giao thức không thể làm cho việc tận dụng hiệu quả các tính năng, tùy chọn mà băng thông rộng cung cấp.

Hơn nữa, giao thức cũ này sẽ tạo ra lưu lượng dữ liệu không cần thiết bởi khi người dùng kết nối tới một Web server, mà không phải là một file server. Các file được truyền tải (transfer) chứ không được tải về (download), vì thế không được copy vào bộ nhớ của thiết bị nhận.

Thực chất thì những điều này đã được xác định khá lâu và tổ chức Internet Engineering Task Force ( IETF ) đã tiếp tục phát triển kỹ thuật đối với website, cập nhật giao thức kết nối kể từ năm 2012.

Và lộ trình để HTTP 2.0 xuất hiện đã sẵn sàng: các chuyên gia đang dự tính giới thiệu nó vào cuối năm 2014. Dự thảo về việc thực hiện đã được phát hành trong tháng 7/2013 và các bài kiểm tra, đánh giá đầu tiên bắt đầu vào tháng 8 sau đó.

Đề xuất cho HTTP 2.0

Năm ngoái, Google và Microsoft đã cung cấp các đề xuất của mình cho sự phát triển kỹ thuật của HTTP 2.0.
SPDY- giao thức được phát triển bởi Google, cạnh tranh với HTTP Speed+Mobility của Microsoft là minh chứng cho việc nỗ lực phát triển nhằm tối ưu hóa tốc độ truy cập. Cả hai đề xuất được tuyên bố nhằm giải quyết những vấn đề mà HTTP 1.1 đang phải đối mặt.
Điểm khác biệt chính yếu là việc HTTP 2.0 có thể mã hóa dữ liệu trong suốt (transparent data). Trong khi SPDY đã được chấp nhận như là cơ sở cho HTTP 2.0, IETF đã bắt đầu ứng dụng với mã hóa bắt buộc trong SPDY bởi vì nó sẽ đòi hỏi năng lực tính toán nhất định từ các thiết bị di động và sẽ giúp làm giảm tuổi thọ pin. Ngoài ra việc bắt buộc mã hóa truy cập đối với các nhà khai thác website nhỏ sẽ gặp nhiều khó khăn bởi những chứng nhận cấp phép khá tốn thời gian và chi phí.

Con đường đi đến giao thức HTTP 2.0 được diễn ra suôn sẻ cho đến khi những tiết lộ của Edward Snowden đã ngăn cản kế hoạch này. Vào đầu tháng 9, những công khai về việc cơ quan tình báo đối ngoại của Mỹ, Cơ quan An ninh Quốc gia (NSA), có thể xâm nhập dữ liệu, thậm chí đánh chặn mã hóa bằng HTTPS trên một quy mô lớn. Chuyên gia mã hóa Bruce Schneier thậm chí còn nói rằng chính phủ Mỹ đã “kiểm soát toàn bộ Internet”. Và hiện tại, trọng tâm của HTTP 2.0 được xác định là An ninh và tính toàn vẹn dữ liệu. Chủ tịch Jari Arkko của IETF đã đặt vấn đề an ninh là chủ đề cho chương trình nghị sự của tổ chức này tại Vancouver trong tháng 11/2014. Cuộc họp này sẽ đánh giá lại cơ bản  nền tảng giao thức liên quan đến những tiết lộ Snowden . Đến lúc đó, tính toàn vẹn của mã hóa web của HTTP 2.0 có thể được đảm bảo thì chương trình phổ cập giao thức mới có thể bắt đầu.

Mã hóa web HTTPS sử dụng SSL và giao thức TLS có sẵn để thiết lập một kết nối an toàn. Mã hóa không đối xứng, bao gồm Public và Private Key được triển khai dưới hình thức: máy chủ sẽ gửi Public Key (khóa công cộng) được chứng nhận cho trình duyệt. Dựa trên việc chứng nhận , trình duyệt đã kiểm tra là hợp lệ thì Session Key sẽ mã hóa đối xứng lưu lượng truy cập dữ liệu và rồi mới gửi đến máy chủ . Các máy chủ sử dụng Private Key (khóa riêng) của mình để trích xuất nội dung chính cho mã hóa đối xứng bằng tin nhắn. Bây giờ máy chủ và trình duyệt đều cùng có tầm quan trọng và có thể mã hóa thông tin giữa hệ thống và thông tin đầu cuối cho người dùng.

NSA xâm nhập vào mã hóa web

Những tổ chức như NSA có thể ghi lại tất cả các lưu lượng truy cập web, có thể giải mã thông tin này sau khi họ nắm giữ Private Key (khóa riêng) của máy chủ thông qua lệnh của tòa án hoặc nhờ vào việc bẻ khóa. Do đó, một gợi ý cho việc triển khai toàn diện các phương pháp khác nhau của thế hệ Key mới đã được triển khai trong khuôn khổ của HTTP 2.0 và giao thức mã hóa TLS 1.3 cũng đang được phát triển. TLS 1.3 sẽ không cho phép trao đổi Key trực tiếp bởi tính năng Perfect Forwoard Secrecy (PFS). Thay vào đó, các máy chủ và trình duyệt giao tiếp với nhau thông qua một số thông điệp và phương pháp mật mã (Diffie-Hellman) dựa trên thế hệ mã hóa đối xứng độc lập mà không phải gửi trực tiếp thông qua web. Nó chỉ hoạt động trong một phiên và bị xóa sau khi phiên giao dịch kết thúc.

PFS đòi hỏi các phương pháp mã hóa được sử dụng để tạo ra các khóa  an toàn. Trong quá khứ, NSA đã tích cực sử dụng phương pháp này và dùng để xâm nhập khi mà các Key này được lưu laị qua các phiên giao dịch. Sau vụ Edward Snowden, công chúng đã biết đến việc hệ thống tạo mật mã Dual_EC_DRBG bị xâm nhập. Dual EC_DRBG đã được phê chuẩn năm 2006 từ Viện Tiêu chuẩn và Công nghệ Quốc gia – NIST và sau đó là Tổ chức Tiêu chuẩn hóa Quốc tế – ISO, có chứa một cửa hậu đã bị NSA chèn vào.

Các nhà phát triển, nhà cung cấp dịch vụ đã đề nghị với IETF hệ thống bảo mật đường cong elip 25519 được phát triển độc lập không phải từ NIST và sử dụng cho TLS 1.3. Bằng cách ngày TLS 1.3 có thể ngăn chặn được việc xâm nhập trực tiếp từ NSA.

Nhưng chỉ có phiên bản TLS mới là không đủ, vẫn còn nghi ngờ mà ngay cả những phương pháp mã hóa RC4, được sử dụng trong HTTPS cũng có chứa một lỗ hổng được cài đặt bởi NSA. RC4 là một phần của giao thức bảo mật hoạt động trên SSL 2.0 cho đến TLS 1.2 sử dụng trong 50% lưu lượng truy cập dữ liệu được mã hóa trên web. Kết quả là, RC4 có thể không còn được xem xét trên TLS 1.3, nhưng hiện tại trong việc thực thi của các lớp bảo mật thì máy chủ quyết định những giao thức được sử dụng. Trong khi các phiên bản trình duyệt mới nhất của Chrome và IE đã triển khai TLS 1.2 thì phần lớn các máy chủ web chủ yếu vẫn sử dụng SSL lỗi thời 3.0 hoặc TLS 1.0.

Sửa lỗi bảo mật trên SSL/TLS

Các cuộc tấn công vào TLS hiện tại là hậu quả của  thực tế khi các gói tin được gửi thêm sau khi luồng dữ liễu đã được ngăn chặn và/hoặc tùy chỉnh. Message Authentication Code (MAC), được chuyển cho tất cả các gói tin thông qua Session Key, có vai trò trung tâm. MAC được tạo thành từ giá trị Băm của các gói dữ liệu và Session Key.

MAC sẽ giúp người nhận xác định xem các gói dữ liệu đi từ người gửi. Như TLS, tất cả các giao thức bảo mật SSL chức năng hiện hành theo phương pháp “MAC rồi sau đó mã hóa “. Do vậy giá trị Băm (Hash) nội dung gói tin không được mã hóa để sử dụng tạo ra các MAC. Đề nghị nâng cấp TLS đã được thực hiện như một biện pháp đối phó, có chức năng theo chiều ngược lại: “Mã hóa sau đó MAC “, giá trị Băm của các gói tin mã hóa được sử dụng để tin tặc không  thể giải mã. Nhưng việc các biện pháp này đủ để ngăn chặn các dịch vụ bí mật rình mò trên toàn cầu là cũng chỉ là dự đoán. Việc tranh cãi liệu HTTP 2.0 có nên được mã hóa trong suốt được nhắc đi nhắc lại trên chương trình nghị sự của Internet Engineering Task Force.

Loại bỏ sai sót

Các thành viên của IETF đã thỏa thuận về công nghệ được sử dụng nhằm loại bỏ vấn đề ảnh hưởng đến hiệu suất liên quan đến HTTP 1.1. Nền tảng cơ sở được sử dụng sẽ là phiên bản 3 giao thức SPDY của Google đã được hỗ trợ bởi các trình duyệt mới nhất như Chrome, IE, Firefox và Opera – Safari của Apple. SPDY giải quyết các lỗ hổng trong cấu trúc HTTP 1.1: các máy chủ cần phải xây dựng một kết nối TCP riêng biệt cho mỗi yếu tố cá nhân. Do đó, nó sẽ khởi động  một số kết nối song song, một lần nữa dẫn tới những đợt dồn dữ liệu không cần thiết, thậm chí, có thể dẫn tới tắc nghẽn lớn, còn gọi là Head-of-Line-Blocking.

Trong Head-of-Line-Blocking, việc xử lý các gói dữ liệu có tổ chức nhờ các gói tin luôn được xử lý theo thứ tự được yêu cầu, không phân biệt là lâu hay mau. Hơn nữa, kết nối HTTP luôn luôn được cài đặt bởi máy chủ Client. Trình duyệt phải kiểm tra liên tục liệu nội dung có bị thay đổi hay không, vì server không tự động cập nhật thông tin.

Mặt khác, một khi kết nối HTTP 2 được thiết lập, trình duyệt và máy chủ có thể tự mở dòng chuyển dữ liệu một cách độc lập. Điều này xảy ra song song và cùng lúc thông qua lệnh ghép.

So với HTTP 1.1,  phiên bản 2.0 cho phép quá trình diễn ra song song trong một kết nối TCP duy nhất. Đặc biệt, điều này làm giảm một lượng lớn tải xuống  trên các trang của máy chủ, mà cần phải xử lý đồng thời nhiều truy vấn của trình duyệt. Các khung cũng được đánh dấu bằng theo trình tự ưu tiên, để trình duyệt hoặc các máy chủ có thể điều chỉnh trình tự giải mã cho phù hợp. Thêm vào đó, máy chủ có thể gửi tin nhắn cho các trình duyệt thông qua lệnh Push.

Ngay cả những tiêu đề gói tin đã được tối ưu hóa trong phiên bản 1.1, HTTP chuyển văn bản hình thức và không nén. Điều này làm dữ liệu lớn lên không cần thiết và cần phải được dịch ra mã nhị phân trước khi được xử lý. Phiên bản 2.0 nén các tiêu đề và gửi chúng trong một mã nhị phân. Điều này về cơ bản làm giảm kích thước khung đầu tiên của các gói dữ liệu, có thể được xử lý nhanh hơn nhiều. Đồng thời độ trễ (thời gian phản ứng) cũng giảm đáng kể.

Nhiều chức năng của HTTP 1.1 và TCP có liên quan với nhau, ví dụ như kết nối song song, bởi vì giao thức TCP cung cấp dịch vụ đang thiếu trong HTTP, theo cách phương đảm bảo các lỗi trong quá trình truyền dữ liệu được phát hiện và sửa chữa và cũng xác định trình tự của các gói tin. Nhưng các chức năng điều khiển một lần nữa làm tăng kích thước của tiêu đề TCP kèm theo độ trễ. Đối với TCP, kết nối được thiết lập như  một cái “bắt tay ba chiều”, một lần nữa lại làm tăng độ trễ.

Nhưng một số tính năng mà TCP cản trở HTTP 2.0, hay đúng hơn, HTTP 2.0 chưa có thỏa thuận cam kết bảo mật ngay bây giờ. Thay vì trình tự gói tin TCP, các ưu tiên được xác định theo cách gói dữ liệu được xử lý. Do đó, Google khuyến cáo sử dụng một phương thức nhanh hơn – nhưng không nên lạm dụng – chính là UDP (User Datagram Protocol ) là giao thức vận chuyển, và đặc biệt là bản chuyên sửa lỗi Google QUIC (Quick UDP Internet Connections). QUIC tiếp nhận dữ liệu, phát hiện lỗi không cần thiết của TCP. Về lâu dài, Google không có ý định thay thế TCP, nhưng sẽ tích hợp QUIC trong đó. Chúng ta có thể mong đợi sự chuyển đổi dễ dàng như từ HTTP 1.1 đến 2.0. Người sử dụng sẽ nhanh chóng nhận được HTTP 2.0 thông qua một bản cập nhật trình duyệt. Trình duyệt sẽ tự động yêu cầu máy chủ nếu nó hỗ trợ 2.0. Nếu có thể làm được như vậy, thì đây chính là tương lai của Internet!

PC World VN, 03/2014