HTTPS

HTTP

Transfer Protocol Security (HTTPS) là một phần mở rộng của Hypertext Transfer Protocol (HTTP). Nó được sử dụng để giao tiếp an toàn qua mạng máy tính và được sử dụng rộng rãi trên Internet. Trong HTTPS, giao thức truyền thông được mã hóa bằng Transport Layer Security (TLS) hay trước đây là Secure Sockets Layer (SSL). Do đó, giao thức này còn được gọi là HTTP qua TLS, hoặc HTTP qua SSL.

Các động cơ chính để dùng HTTPS là xác thực trang web được truy cập và bảo vệ quyền riêng tư và tính toàn vẹn của dữ liệu được trao đổi trong khi truyền. Nó bảo vệ chống lại các cuộc tấn công của kẻ trung gian và mã hóa hai chiều của giao tiếp giữa máy khách và máy chủ bảo vệ thông tin liên lạc khỏi bị nghe trộm và giả mạo. Khía cạnh xác thực của HTTPS yêu cầu một bên thứ ba đáng tin cậy ký các chứng chỉ số phía máy chủ. Trước đây, đây là một hoạt động tốn kém, có nghĩa là các kết nối HTTPS đã được xác thực hoàn toàn thường chỉ được tìm thấy trên các dịch vụ giao dịch thanh toán bảo đảm và các hệ thống thông tin công ty được bảo mật khác trên World Wide Web. Vào năm 2016, một chiến dịch của Electronic Frontier Foundation với sự hỗ trợ của các nhà phát triển trình duyệt web đã khiến giao thức này trở nên phổ biến hơn. HTTPS hiện được người dùng web sử dụng thường xuyên hơn so với HTTP không an toàn ban đầu, chủ yếu để bảo vệ tính xác thực của trang trên tất cả các loại trang web; tài khoản an toàn; và giữ bí mật thông tin liên lạc, danh tính và duyệt web của người dùng.

Tổng quan

Lưu trữ 2020-09-29 tại Wayback MachineURL bắt đầu bằng lược đồ HTTPS và nhãn tên miền WWW

Lược đồ định danh tài nguyên đồng nhất (URI) HTTPS có cú pháp sử dụng giống hệt với lược đồ HTTP. Tuy nhiên, HTTPS báo hiệu trình duyệt sử dụng một lớp mã hóa bổ sung SSL/TLS để bảo vệ lưu lượng truy cập. SSL/TLS đặc biệt phù hợp với HTTP, vì nó có thể cung cấp một số biện pháp bảo vệ ngay cả khi chỉ một bên của giao tiếp được xác thực. Đây là trường hợp của các giao dịch HTTP qua Internet, trong đó thường chỉ máy chủ được xác thực (bằng cách khách hàng kiểm tra chứng chỉ của máy chủ).

HTTPS tạo ra một kênh an toàn qua một mạng không an toàn. Điều này đảm bảo sự bảo vệ hợp lý khỏi những kẻ nghe trộm và các cuộc tấn công trung gian, với điều kiện sử dụng các bộ mật mã thích hợp và chứng chỉ máy chủ được xác minh và đáng tin cậy.

Vì HTTPS dựa hoàn toàn vào HTTP trên TLS nên toàn bộ giao thức HTTP bên dưới có thể được mã hóa. Điều này bao gồm URL yêu cầu (trang web cụ thể đã được yêu cầu), tham số truy vấn, tiêu đề và cookie (thường chứa thông tin nhận dạng về người dùng). Tuy nhiên, vì địa chỉ trang web và số cổng nhất thiết phải là một phần của giao thức TCP/IP cơ bản, HTTPS không thể bảo vệ sự tiết lộ của chúng. Trên thực tế, điều này có nghĩa là ngay cả trên một máy chủ web được định cấu hình chính xác, những kẻ nghe trộm có thể suy ra địa chỉ IP và số cổng của máy chủ web và đôi khi thậm chí cả tên miền (ví dụ: www.example.org, nhưng không phải phần còn lại của URL) người dùng đang liên lạc, cùng với lượng dữ liệu được truyền và thời lượng liên lạc, mặc dù đó không phải là nội dung của việc liên lạc.^[1]

Các trình duyệt web tin cậy các trang web HTTPS dựa trên các tổ chức phát hành chứng chỉ được cài đặt sẵn trong phần mềm của họ. Cơ quan cấp chứng chỉ theo cách này được người tạo trình duyệt web tin cậy để cung cấp chứng chỉ hợp lệ. Do đó, người dùng nên tin tưởng kết nối HTTPS với một trang web khi và chỉ khi tất cả những điều sau là đúng:

• Người dùng tin tưởng rằng phần mềm trình duyệt triển khai chính xác HTTPS với các tổ chức phát hành chứng chỉ được cài đặt sẵn một cách chính xác.
• Người dùng tin tưởng tổ chức phát hành chứng chỉ chỉ bảo đảm cho các trang web hợp pháp.
• Trang web cung cấp một chứng chỉ hợp lệ, có nghĩa là nó đã được ký bởi một cơ quan đáng tin cậy.
• Chứng chỉ xác định chính xác trang web (ví dụ: khi trình duyệt truy cập " https://example.com ", chứng chỉ nhận được chính xác cho "example.com" chứ không phải một số thực thể khác).
• Người dùng tin tưởng rằng lớp mã hóa của giao thức (SSL/TLS) đủ an toàn để chống lại những kẻ nghe trộm.

HTTPS đặc biệt quan trọng đối với các mạng không an toàn và mạng có thể bị giả mạo. Các mạng không an toàn, chẳng hạn như các điểm truy cập Wi-Fi công cộng, cho phép bất kỳ ai trong cùng một mạng cục bộ có thể dò tìm gói và phát hiện ra thông tin nhạy cảm không được bảo vệ bởi HTTPS. Ngoài ra, một số mạng WLAN miễn phí sử dụng và trả phí đã được quan sát thấy giả mạo các trang web bằng cách tham gia vào việc đưa vào gói để phân phát quảng cáo của chính họ trên các trang web khác. Phương thức này có thể bị lợi dụng một cách ác ý theo nhiều cách, chẳng hạn như bằng cách đưa phần mềm độc hại vào các trang web và đánh cắp thông tin cá nhân của người dùng.^[2]

HTTPS cũng rất quan trọng đối với các kết nối qua mạng ẩn danh Tor, vì các nút Tor độc hại có thể làm hỏng hoặc thay đổi nội dung đi qua chúng theo cách không an toàn và đưa phần mềm độc hại vào kết nối. Đây là một lý do tại sao Electronic Frontier Foundation và dự án Tor bắt đầu phát triển HTTPS Everywhere,^[1] được bao gồm trong Tor Browser Bundle.^[3]

Khi nhiều thông tin được tiết lộ về việc giám sát hàng loạt quy mô toàn cầu và tội phạm ăn cắp thông tin cá nhân, việc sử dụng bảo mật HTTPS trên tất cả các trang web ngày càng trở nên quan trọng bất kể loại kết nối Internet đang được sử dụng.^[4][5] Mặc dù siêu dữ liệu về các trang riêng lẻ mà người dùng truy cập có thể không được coi là nhạy cảm, nhưng khi được tổng hợp lại, siêu dữ liệu có thể tiết lộ rất nhiều về người dùng và xâm phạm quyền riêng tư của người dùng.^[6][7][8]

Việc triển khai HTTPS cũng cho phép sử dụng HTTP/2 (hoặc giao thức tiền thân của nó, giao thức SPDY hiện không được dùng nữa), là một thế hệ HTTP mới được thiết kế để giảm thời gian tải trang, kích thước và độ trễ.

Có các khuyến nghị sử dụng HTTP Strict Transport Security (HSTS) với HTTPS để bảo vệ người dùng khỏi các cuộc tấn công trung gian, đặc biệt là việc tước bỏ SSL.^[8][9]

Không nên nhầm lẫn HTTPS với Secure HTTP (S-HTTP) hiếm khi được sử dụng được chỉ định trong RFC 2660.

Sử dụng trong các trang web

Tính đến tháng 4 năm 2018^{[cập nhật]}, 33,2% trong số 1.000.000 trang web hàng đầu của Alexa sử dụng HTTPS làm mặc định,^[10] 57,1% trong số 137.971 trang web phổ biến nhất trên Internet có triển khai HTTPS an toàn,^[11] và 70% số lần tải trang (đo bằng Firefox Telemetry) sử dụng HTTPS.^[12]

Tích hợp trình duyệt

Hầu hết các trình duyệt hiển thị cảnh báo nếu họ nhận được chứng chỉ không hợp lệ. Các trình duyệt cũ hơn, khi kết nối với một trang web có chứng chỉ không hợp lệ, sẽ hiển thị cho người dùng một hộp thoại hỏi họ có muốn tiếp tục hay không. Các trình duyệt mới hơn hiển thị cảnh báo trên toàn bộ cửa sổ. Các trình duyệt mới hơn cũng hiển thị nổi bật thông tin bảo mật của trang web trong thanh địa chỉ. Chứng chỉ xác thực mở rộng chuyển thanh địa chỉ sang màu xanh lục trong các trình duyệt mới hơn. Hầu hết các trình duyệt cũng hiển thị cảnh báo cho người dùng khi truy cập trang web có chứa hỗn hợp nội dung được mã hóa và không được mã hóa. Ngoài ra, nhiều bộ lọc web trả lại cảnh báo bảo mật khi truy cập các trang web bị cấm.

Electronic Frontier Foundation tuyên bố rằng "Trong một thế giới lý tưởng, mọi yêu cầu web đều có thể được đặt mặc định thành HTTPS", đã cung cấp một tiện ích bổ sung có tên HTTPS Everywhere cho Mozilla Firefox, Google Chrome, Chromium và Android, cho phép HTTPS theo mặc định cho hàng trăm trang web được sử dụng thường xuyên.^[13][14]

Bảo mật

Tính bảo mật của HTTPS là TLS bên dưới, thường sử dụng khóa công khai và khóa riêng dài hạn để tạo khóa phiên ngắn hạn, khóa này sau đó được sử dụng để mã hóa luồng dữ liệu giữa máy khách và máy chủ. Chứng chỉ X.509 được sử dụng để xác thực máy chủ (và đôi khi cả máy khách). Do đó, cơ quan cấp chứng chỉ và chứng chỉ khóa công khai là cần thiết để xác minh mối quan hệ giữa chứng chỉ và chủ sở hữu của nó, cũng như để tạo, ký và quản lý hiệu lực của chứng chỉ. Mặc dù điều này có thể có lợi hơn việc xác minh danh tính thông qua một trang web tin cậy, nhưng các tiết lộ giám sát hàng loạt năm 2013 đã thu hút sự chú ý của các cơ quan cấp chứng chỉ như một điểm yếu tiềm ẩn cho phép tấn công kẻ trung gian.^[15][16] Một thuộc tính quan trọng trong bối cảnh này là tính bí mật về phía trước, đảm bảo rằng thông tin liên lạc được mã hóa được ghi lại trong quá khứ không thể được truy xuất và giải mã nếu khóa bí mật lâu dài hoặc mật khẩu bị xâm phạm trong tương lai. Không phải tất cả các máy chủ web đều cung cấp bí mật chuyển tiếp.^{[17] [Cần cập nhật]}

Để HTTPS có hiệu quả, một trang web phải được lưu trữ hoàn toàn qua HTTPS. Nếu một số nội dung của trang web được tải qua HTTP (ví dụ: tập lệnh hoặc hình ảnh) hoặc nếu chỉ một trang nhất định chứa thông tin nhạy cảm, chẳng hạn như trang đăng nhập, được tải qua HTTPS trong khi phần còn lại của trang web được tải qua HTTP đơn giản, người dùng sẽ dễ bị tấn công và giám sát. Ngoài ra, cookie trên một trang web được phân phát thông qua HTTPS phải được bật thuộc tính bảo mật. Trên một trang web có thông tin nhạy cảm trên đó, người dùng và phiên sẽ bị hiển thị mỗi khi trang web đó được truy cập bằng HTTP thay vì HTTPS.^[8]

Kỹ thuật

Điểm khác biệt với HTTP

Các URL HTTPS bắt đầu bằng "https://" và sử dụng cổng 443 theo mặc định, trong khi các URL HTTP bắt đầu bằng "http://" và sử dụng cổng 80 theo mặc định.

HTTP không được mã hóa và do đó dễ bị tấn công kẻ trung gian và nghe trộm, có thể cho phép những kẻ tấn công có quyền truy cập vào tài khoản trang web và thông tin nhạy cảm, đồng thời sửa đổi trang web để đưa phần mềm độc hại hoặc quảng cáo vào. HTTPS được thiết kế để chống lại các cuộc tấn công như vậy và được coi là an toàn trước chúng (ngoại trừ việc triển khai HTTPS sử dụng các phiên bản SSL không dùng nữa).

Các tầng mạng

HTTP hoạt động ở tầng cao nhất của mô hình TCP/IP — tầng ứng dụng; cũng như giao thức bảo mật TLS (hoạt động như một tầng con thấp hơn của cùng một tầng), mã hóa một thông điệp HTTP trước khi truyền và giải mã một thông báo khi đến. Nói một cách chính xác, HTTPS không phải là một giao thức riêng biệt, mà đề cập đến việc sử dụng HTTP thông thường qua kết nối SSL/TLS được mã hóa.

HTTPS mã hóa tất cả nội dung gửi đi, bao gồm tiêu đề HTTP và dữ liệu yêu cầu / phản hồi. Ngoại trừ cuộc tấn công mật mã CCA có thể xảy ra được mô tả trong phần giới hạn bên dưới, kẻ tấn công ít nhất phải có thể phát hiện ra rằng kết nối đang diễn ra giữa hai bên, cùng với tên miền và địa chỉ IP của họ.

Thiết lập máy chủ

Để chuẩn bị máy chủ web chấp nhận kết nối HTTPS, quản trị viên phải tạo chứng chỉ khóa công khai cho máy chủ web. Chứng chỉ này phải được ký bởi tổ chức phát hành chứng chỉ đáng tin cậy để trình duyệt web chấp nhận nó mà không cần cảnh báo. Cơ quan có thẩm quyền xác nhận rằng chủ sở hữu chứng chỉ là người điều hành máy chủ web cung cấp nó. Các trình duyệt web thường được phân phối với một danh sách các chứng chỉ đã ký của các cơ quan cấp chứng chỉ chính để cơ quan cấp chứng chỉ có thể xác minh các chứng chỉ do các trình duyệt ký.

Nhận chứng chỉ

Một số tổ chức cung cấp chứng chỉ thương mại tồn tại, cung cấp chứng chỉ SSL / TLS trả phí thuộc một số loại, bao gồm cả Chứng chỉ xác thực mở rộng.

Let's Encrypt, ra mắt vào tháng 4 năm 2016,^[18] cung cấp dịch vụ tự động và miễn phí cung cấp chứng chỉ SSL/TLS cơ bản cho các trang web.^[19] Theo Electronic Frontier Foundation, Let's Encrypt sẽ giúp việc chuyển đổi từ HTTP sang HTTPS "dễ dàng như đưa ra một lệnh hoặc nhấp vào một nút." ^[20] Phần lớn các nhà cung cấp dịch vụ lưu trữ web và đám mây hiện tận dụng Let's Encrypt, cung cấp chứng chỉ miễn phí cho khách hàng của họ.

Sử dụng như cách kiểm soát truy cập

HTTPS cũng có thể được sử dụng để xác thực máy khách nhằm giới hạn quyền truy cập vào máy chủ web đối với người dùng được ủy quyền. Để làm điều này, quản trị viên trang web thường tạo chứng chỉ cho mỗi người dùng, chứng chỉ này người dùng tải vào trình duyệt của họ. Thông thường, chứng chỉ chứa tên và địa chỉ e-mail của người dùng được ủy quyền và được máy chủ tự động kiểm tra trên mỗi kết nối để xác minh danh tính của người dùng, thậm chí có thể không yêu cầu mật khẩu.

Trong trường hợp khóa bí mật (riêng tư) bị lộ

Một đặc tính quan trọng trong bối cảnh này là tính bảo mật chuyển tiếp hoàn hảo (PFS). Sở hữu một trong những khóa bí mật bất đối xứng dài hạn được sử dụng để thiết lập phiên HTTPS sẽ không giúp dễ dàng hơn trong việc lấy khóa phiên ngắn hạn để sau đó giải mã cuộc hội thoại, ngay cả sau đó. Trao đổi khóa Diffie-Hellman (DHE) và trao đổi khóa đường cong ellip Diffie-Hellman (ECDHE) là những chương trình duy nhất được biết đến là có thuộc tính đó vào năm 2013. Trong năm 2013, chỉ có 30% phiên trình duyệt Firefox, Opera và Chromium và gần 0% phiên Safari của Apple và Microsoft Internet Explorer sử dụng nó.^[17] TLS 1.3, được đưa ra vào tháng 8 năm 2018, đã bỏ hỗ trợ cho mật mã mà không có bí mật chuyển tiếp. Tính đến tháng 2 năm 2020^{[cập nhật]} , 96,6% máy chủ web được khảo sát hỗ trợ một số hình thức bảo mật chuyển tiếp và 52,1% sẽ sử dụng bảo mật chuyển tiếp với hầu hết các trình duyệt.^[21]

Một chứng chỉ có thể bị thu hồi trước khi hết hạn, chẳng hạn như vì tính bí mật của khóa cá nhân đã bị xâm phạm. Các phiên bản mới hơn của các trình duyệt phổ biến như Firefox,^[22] Opera,^[23] và Internet Explorer trên Windows Vista ^[24] triển khai Giao thức Trạng thái Chứng chỉ Trực tuyến (OCSP) để xác minh rằng đây không phải là trường hợp. Trình duyệt gửi số sê-ri của chứng chỉ đến tổ chức phát hành chứng chỉ hoặc người được ủy quyền của tổ chức đó qua OCSP (Giao thức trạng thái chứng chỉ trực tuyến) và tổ chức này sẽ phản hồi, thông báo cho trình duyệt biết chứng chỉ có còn hợp lệ hay không.^[25] CA cũng có thể cấp CRL để cho mọi người biết rằng các chứng chỉ này đã bị thu hồi.

Các giới hạn

Mã hóa SSL (Secure Sockets Layer) và TLS (Transport Layer Security) có thể được cấu hình ở hai chế độ: đơn giản và tương hỗ . Trong chế độ đơn giản, xác thực chỉ được thực hiện bởi máy chủ. Phiên bản tương hỗ yêu cầu người dùng cài đặt chứng chỉ máy khách cá nhân trong trình duyệt web để xác thực người dùng.^[26] Trong cả hai trường hợp, mức độ bảo vệ phụ thuộc vào tính đúng đắn của việc triển khai phần mềm và các thuật toán mã hóa sử dụng.

SSL/TLS không ngăn chặn việc lập chỉ mục trang web bởi trình thu thập thông tin và trong một số trường hợp, URI của tài nguyên được mã hóa có thể được suy ra bằng cách chỉ biết kích thước yêu cầu / phản hồi bị chặn.^[27] Điều này cho phép kẻ tấn công có quyền truy cập vào bản rõ (nội dung tĩnh có sẵn công khai) và văn bản được mã hóa (phiên bản được mã hóa của nội dung tĩnh), cho phép tấn công bằng mật mã.

Vì TLS hoạt động ở cấp độ giao thức thấp hơn HTTP và không có kiến thức về các giao thức cấp độ cao hơn, máy chủ TLS chỉ có thể hiển thị đúng một chứng chỉ cho một tổ hợp địa chỉ và cổng cụ thể.^[28] Trước đây, điều này có nghĩa là không khả thi khi sử dụng dịch vụ lưu trữ ảo dựa trên tên với HTTPS. Có một giải pháp được gọi là Chỉ báo tên máy chủ (SNI), sẽ gửi tên máy chủ đến máy chủ trước khi mã hóa kết nối, mặc dù nhiều trình duyệt cũ không hỗ trợ tiện ích mở rộng này. Hỗ trợ cho SNI có sẵn kể từ Firefox 2, Opera 8, Apple Safari 2.1, Google Chrome 6 và Internet Explorer 7 trên Windows Vista.^[29][30][31]

Theo quan điểm kiến trúc hệ thống:

• Kết nối SSL/TLS được máy tính đầu tiên khởi tạo kết nối TLS quản lý. Nếu vì bất kỳ lý do nào (định tuyến, tối ưu hóa lưu lượng, v.v.), máy chủ này không phải là máy chủ ứng dụng và nó phải giải mã dữ liệu, thì phải tìm ra các giải pháp để truyền thông tin xác thực người dùng hoặc chứng chỉ tới máy chủ ứng dụng, cần phải biết ai sẽ được kết nối.
• Đối với SSL/TLS có xác thực lẫn nhau, phiên SSL/TLS được máy chủ đầu tiên khởi tạo kết nối quản lý. Trong các tình huống mã hóa phải được phổ biến dọc theo các máy chủ chuỗi, việc quản lý session timeOut trở nên cực kỳ khó thực hiện.
• Bảo mật là tối đa với SSL/TLS tương hỗ, nhưng ở phía máy khách, không có cách nào để kết thúc đúng cách kết nối SSL/TLS và ngắt kết nối người dùng ngoại trừ bằng cách đợi phiên máy chủ hết hạn hoặc bằng cách đóng tất cả các ứng dụng máy khách liên quan.

Một kiểu tấn công man-in-the-middle tinh vi được gọi là tước đi SSL đã được trình bày tại Hội nghị Blackhat năm 2009. Kiểu tấn công này đánh bại sự bảo mật do HTTPS cung cấp bằng cách thay đổi liên kết https: thành liên kết http: :, lợi dụng thực tế là ít người dùng Internet thực sự nhập "https" vào giao diện trình duyệt của họ: họ truy cập vào một trang web an toàn bằng cách nhấp vào một liên kết và do đó bị đánh lừa rằng họ đang sử dụng HTTPS trong khi thực tế là họ đang sử dụng HTTP. Sau đó kẻ tấn công giao tiếp với khách hàng.^[32] Điều này đã thúc đẩy sự phát triển của một biện pháp đối phó trong HTTP được gọi là HTTP Strict Transport Security.

HTTPS đã được chứng minh là dễ bị tấn công bởi một loạt các cuộc tấn công phân tích lưu lượng. Các cuộc tấn công phân tích lưu lượng là một loại tấn công kênh phụ dựa trên các biến thể về thời gian và kích thước của lưu lượng truy cập để suy ra các thuộc tính về chính lưu lượng được mã hóa. Có thể phân tích lưu lượng vì mã hóa SSL / TLS thay đổi nội dung của lưu lượng, nhưng có tác động tối thiểu đến quy mô và thời gian của lưu lượng. Vào tháng 5 năm 2010, một bài báo nghiên cứu của các nhà nghiên cứu từ Microsoft Research và Đại học Indiana đã phát hiện ra rằng dữ liệu người dùng nhạy cảm chi tiết có thể được suy ra từ các kênh phụ như kích thước gói. Các nhà nghiên cứu phát hiện ra rằng, mặc dù có được bảo vệ HTTPS trong một số ứng dụng web hàng đầu, cao cấp trong lĩnh vực chăm sóc sức khỏe, thuế, đầu tư và tìm kiếm trên web, kẻ nghe trộm có thể suy ra bệnh/thuốc /phẫu thuật/ thu nhập gia đình và bí mật đầu tư của người dùng.^[33] Mặc dù công trình này đã chứng minh tính dễ bị tổn thương của HTTPS đối với phân tích lưu lượng, nhưng cách tiếp cận mà các tác giả trình bày yêu cầu phân tích thủ công và tập trung đặc biệt vào các ứng dụng web được HTTPS bảo vệ.

Thực tế là hầu hết các trang web hiện đại, bao gồm Google, Yahoo !, và Amazon, sử dụng HTTPS gây ra sự cố cho nhiều người dùng khi cố gắng truy cập các điểm phát Wi-Fi công cộng, vì trang đăng nhập điểm phát Wi-Fi không tải được nếu người dùng cố gắng mở tài nguyên HTTPS.^[34] Một số trang web, chẳng hạn như neverssl.com và nonhttps.com, đảm bảo rằng chúng sẽ luôn có thể truy cập được bằng HTTP.^[35][36]

Lịch sử

Netscape Communications đã tạo ra HTTPS vào năm 1994 cho trình duyệt web Netscape Navigator.^[37] Ban đầu, HTTPS được sử dụng với giao thức SSL. Khi SSL phát triển thành Bảo mật tầng truyền tải (TLS), HTTPS được RFC 2818 chính thức xác định vào tháng 5 năm 2000. Google đã thông báo vào tháng 2 năm 2018 rằng trình duyệt Chrome của họ sẽ đánh dấu các trang web HTTP là "Không an toàn" sau tháng 7 năm 2018.^[38] Động thái này nhằm khuyến khích chủ sở hữu trang web triển khai HTTPS, như một nỗ lực để làm cho World Wide Web an toàn hơn.

Tham khảo

1. ^ “HTTPS Everywhere FAQ”. 8 tháng 11 năm 2016. Bản gốc lưu trữ ngày 14 tháng 11 năm 2018. Truy cập ngày 20 tháng 10 năm 2018.
2. “Hotel Wifi JavaScript Injection”. JustInsomnia. 3 tháng 4 năm 2012. Bản gốc lưu trữ ngày 18 tháng 11 năm 2018. Truy cập ngày 20 tháng 10 năm 2018.
3. The Tor Project, Inc. “What is Tor Browser?”. TorProject.org. Bản gốc lưu trữ ngày 17 tháng 7 năm 2013. Truy cập ngày 30 tháng 5 năm 2012.
4. Konigsburg, Eitan; Pant, Rajiv; Kvochko, Elena (13 tháng 11 năm 2014). “Embracing HTTPS”. The New York Times. Bản gốc lưu trữ ngày 8 tháng 1 năm 2019. Truy cập ngày 20 tháng 10 năm 2018.
5. Gallagher, Kevin (12 tháng 9 năm 2014). “Fifteen Months After the NSA Revelations, Why Aren't More News Organizations Using HTTPS?”. Freedom of the Press Foundation. Bản gốc lưu trữ ngày 10 tháng 8 năm 2018. Truy cập ngày 20 tháng 10 năm 2018.
6. “HTTPS as a ranking signal”. Google Webmaster Central Blog. Google Inc. 6 tháng 8 năm 2014. Bản gốc lưu trữ ngày 17 tháng 10 năm 2018. Truy cập ngày 20 tháng 10 năm 2018. You can make your site secure with HTTPS (Hypertext Transfer Protocol Secure) [...]
7. Grigorik, Ilya; Far, Pierre (26 tháng 6 năm 2014). “Google I/O 2014 - HTTPS Everywhere”. Google Developers. Bản gốc lưu trữ ngày 20 tháng 11 năm 2018. Truy cập ngày 20 tháng 10 năm 2018.
8. ^ “How to Deploy HTTPS Correctly”. 15 tháng 11 năm 2010. Bản gốc lưu trữ ngày 10 tháng 10 năm 2018. Truy cập ngày 20 tháng 10 năm 2018.
9. “HTTP Strict Transport Security”. Mozilla Developer Network. Bản gốc lưu trữ ngày 19 tháng 10 năm 2018. Truy cập ngày 20 tháng 10 năm 2018.
10. “HTTPS usage statistics on top 1M websites”. StatOperator.com. Bản gốc lưu trữ ngày 9 tháng 2 năm 2019. Truy cập ngày 20 tháng 10 năm 2018.
11. “Qualys SSL Labs - SSL Pulse”. www.ssllabs.com. 3 tháng 4 năm 2018. Bản gốc lưu trữ ngày 2 tháng 12 năm 2017. Truy cập ngày 20 tháng 10 năm 2018.
12. “Let's Encrypt Stats”. LetsEncrypt.org. Bản gốc lưu trữ ngày 19 tháng 10 năm 2018. Truy cập ngày 20 tháng 10 năm 2018.
13. Eckersley, Peter (17 tháng 6 năm 2010). “Encrypt the Web with the HTTPS Everywhere Firefox Extension”. EFF blog. Bản gốc lưu trữ ngày 25 tháng 11 năm 2018. Truy cập ngày 20 tháng 10 năm 2018.
14. “HTTPS Everywhere”. EFF projects. 7 tháng 10 năm 2011. Bản gốc lưu trữ ngày 5 tháng 6 năm 2011. Truy cập ngày 20 tháng 10 năm 2018.
15. Singel, Ryan (ngày 24 tháng 3 năm 2010). “Law Enforcement Appliance Subverts SSL”. Wired. Bản gốc lưu trữ ngày 17 tháng 1 năm 2019. Truy cập ngày 20 tháng 10 năm 2018.
16. Schoen, Seth (24 tháng 3 năm 2010). “New Research Suggests That Governments May Fake SSL Certificates”. EFF. Bản gốc lưu trữ ngày 4 tháng 1 năm 2016. Truy cập ngày 20 tháng 10 năm 2018.
17. ^ Duncan, Robert (25 tháng 6 năm 2013). “SSL: Intercepted today, decrypted tomorrow”. Netcraft. Bản gốc lưu trữ ngày 6 tháng 10 năm 2018. Truy cập ngày 20 tháng 10 năm 2018.
18. Cimpanu, Catalin (12 tháng 4 năm 2016). “Let's Encrypt Launched Today, Currently Protects 3.8 Million Domains”. Softpedia News. Bản gốc lưu trữ ngày 9 tháng 2 năm 2019. Truy cập ngày 20 tháng 10 năm 2018.
19. Kerner, Sean Michael (18 tháng 11 năm 2014). “Let's Encrypt Effort Aims to Improve Internet Security”. eWeek.com. Quinstreet Enterprise. Truy cập ngày 20 tháng 10 năm 2018.
20. Eckersley, Peter (18 tháng 11 năm 2014). “Launching in 2015: A Certificate Authority to Encrypt the Entire Web”. Electronic Frontier Foundation. Bản gốc lưu trữ ngày 18 tháng 11 năm 2018. Truy cập ngày 20 tháng 10 năm 2018.
21. Qualys SSL Labs. “SSL Pulse”. Bản gốc (ngày 3 tháng 2 năm 2019) lưu trữ ngày 15 tháng 2 năm 2019. Truy cập ngày 25 tháng 2 năm 2019.
22. “Mozilla Firefox Privacy Policy”. Mozilla Foundation. 27 tháng 4 năm 2009. Bản gốc lưu trữ ngày 18 tháng 10 năm 2018. Truy cập ngày 20 tháng 10 năm 2018.
23. “Opera 8 launched on FTP”. Softpedia. ngày 19 tháng 4 năm 2005. Bản gốc lưu trữ ngày 9 tháng 2 năm 2019. Truy cập ngày 20 tháng 10 năm 2018.
24. Lawrence, Eric (31 tháng 1 năm 2006). “HTTPS Security Improvements in Internet Explorer 7”. MSDN. Bản gốc lưu trữ ngày 20 tháng 10 năm 2018. Truy cập ngày 20 tháng 10 năm 2018.
25. Myers, Michael; Ankney, Rich; Malpani, Ambarish; Galperin, Slava; Adams, Carlisle (20 tháng 6 năm 1999). “Online Certificate Status Protocol – OCSP”. Internet Engineering Task Force. Bản gốc lưu trữ ngày 25 tháng 8 năm 2011. Truy cập ngày 20 tháng 10 năm 2018.
26. “Manage client certificates on Chrome devices – Chrome for business and education Help”. support.google.com. Bản gốc lưu trữ ngày 9 tháng 2 năm 2019. Truy cập ngày 20 tháng 10 năm 2018.
27. Pusep, Stanislaw (31 tháng 7 năm 2008). “The Pirate Bay un-SSL” (PDF). Bản gốc (PDF) lưu trữ ngày 20 tháng 6 năm 2018. Truy cập ngày 20 tháng 10 năm 2018.
28. “SSL/TLS Strong Encryption: FAQ”. apache.org. Bản gốc lưu trữ ngày 19 tháng 10 năm 2018. Truy cập ngày 20 tháng 10 năm 2018.
29. Lawrence, Eric (22 tháng 10 năm 2005). “Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2”. Microsoft. Bản gốc lưu trữ ngày 20 tháng 9 năm 2018. Truy cập ngày 20 tháng 10 năm 2018.
30. “Server Name Indication (SNI)”. inside aebrahim's head. 21 tháng 2 năm 2006. Bản gốc lưu trữ ngày 10 tháng 8 năm 2018. Truy cập ngày 20 tháng 10 năm 2018.
31. Pierre, Julien (19 tháng 12 năm 2001). “Browser support for TLS server name indication”. Bugzilla. Mozilla Foundation. Bản gốc lưu trữ ngày 8 tháng 10 năm 2018. Truy cập ngày 20 tháng 10 năm 2018.
32. “sslstrip 0.9”. Bản gốc lưu trữ ngày 20 tháng 6 năm 2018. Truy cập ngày 20 tháng 10 năm 2018.
33. Shuo Chen; Rui Wang; XiaoFeng Wang; Kehuan Zhang (ngày 20 tháng 5 năm 2010). “Side-Channel Leaks in Web Applications: a Reality Today, a Challenge Tomorrow”. Microsoft Research. IEEE Symposium on Security & Privacy 2010. Bản gốc lưu trữ ngày 22 tháng 7 năm 2018. Truy cập ngày 20 tháng 10 năm 2018.
34. Guaay, Matthew (21 tháng 9 năm 2017). “How to Force a Public Wi-Fi Network Login Page to Open”. Bản gốc lưu trữ ngày 10 tháng 8 năm 2018. Truy cập ngày 20 tháng 10 năm 2018.
35. “NeverSSL”. Bản gốc lưu trữ ngày 1 tháng 9 năm 2018. Truy cập ngày 20 tháng 10 năm 2018.
36. “a non https website”. Bản gốc lưu trữ ngày 17 tháng 10 năm 2018. Truy cập ngày 20 tháng 10 năm 2018.
37. Walls, Colin (2005). Embedded Software: The Works. Newnes. tr. 344. ISBN 0-7506-7954-9. Bản gốc lưu trữ ngày 9 tháng 2 năm 2019. Truy cập ngày 20 tháng 10 năm 2018.
38. “A secure web is here to stay”. Chromium Blog. Bản gốc lưu trữ ngày 24 tháng 4 năm 2019. Truy cập ngày 22 tháng 4 năm 2019.