Các tiêu đề HTTPS có được mã hóa không?

600

Khi gửi dữ liệu qua HTTPS, tôi biết nội dung được mã hóa, tuy nhiên tôi nghe thấy các câu trả lời hỗn hợp về việc các tiêu đề được mã hóa hay bao nhiêu tiêu đề được mã hóa.

Có bao nhiêu tiêu đề HTTPS được mã hóa?

Bao gồm URL yêu cầu GET / POST, Cookies, v.v.

— Dan Herbert
nguồn

9

Tiêu đề HTTP trên HTTPS được mã hóa và cũng không được nén HTTP (ngay cả khi phần thân là). Điều này làm cho chúng ít bị tổn thương hơn trước các cuộc tấn công liên quan đến nén như BEAST

— Neil McGuigan

552

Toàn bộ lô được mã hóa ^† - tất cả các tiêu đề. Đó là lý do tại sao SSL trên vhost không hoạt động tốt - bạn cần một địa chỉ IP chuyên dụng vì tiêu đề Máy chủ được mã hóa.

^† Server Name Xác (SNI) có nghĩa là tiêu chuẩn mà tên máy có thể không được mã hóa nếu bạn đang sử dụng TLS. Ngoài ra, cho dù bạn có sử dụng SNI hay không, các tiêu đề TCP và IP không bao giờ được mã hóa. (Nếu có, các gói của bạn sẽ không thể định tuyến được.)

— Greg
nguồn

3

@Greg, Vì cổng vhost được ủy quyền, nên cổng không thể mã hóa chúng, quan sát tiêu đề Máy chủ, sau đó xác định máy chủ nào sẽ gửi các gói đến?

— Pacerier

2

URL Afaik tự nó không được mã hóa.

— Teddy

4

@Teddu, ý của bạn là "URL không được mã hóa." Nó được mã hóa, vì nó là một phần của tiêu đề.

— Dmitry Polushkin

1

Nếu Fiddler được sử dụng để ghi lại giao tiếp https, nó vẫn hiển thị một số tiêu đề, tại sao? Đặc biệt, khi kết nối internet thông qua một proxy yêu cầu xác thực, nó sẽ hiển thị tiêu đề Ủy quyền Proxy khi yêu cầu được gửi lại sau khi nhận được 407 ở lần gửi đầu tiên.

— Bochen Lin

1

@Bochen giống như cách mà Pegasus làm. Nếu bạn ở hai đầu của đường hầm HTTPS thì bạn có thể thấy mọi thứ. Tương tự như vậy tôi có thể thấy bất cứ điều gì trong devtools trình duyệt.

— Nux

97

Các tiêu đề được mã hóa hoàn toàn. Thông tin duy nhất trên mạng 'rõ ràng' có liên quan đến thiết lập SSL và trao đổi khóa D / H. Trao đổi này được thiết kế cẩn thận để không mang lại bất kỳ thông tin hữu ích nào cho những kẻ nghe trộm, và một khi nó đã diễn ra, tất cả dữ liệu được mã hóa.

— mdb
nguồn

4

Không phải tất cả các thiết lập SSL liên quan đến DH

— Dori

30

Nói một cách khoa trương: Địa chỉ IP của máy khách và máy chủ, tên máy chủ của máy chủ và các tín hiệu về việc triển khai SSL của chúng rất hữu ích đối với những kẻ nghe trộm và có thể nhìn thấy.

— poolie

66

Câu trả lời mới cho câu hỏi cũ, xin lỗi. Tôi nghĩ tôi sẽ thêm $ 0,02 của mình

OP hỏi nếu các tiêu đề được mã hóa.

Đó là: quá cảnh.

Họ KHÔNG: khi không quá cảnh.

Vì vậy, URL của trình duyệt của bạn (và tiêu đề, trong một số trường hợp) có thể hiển thị chuỗi truy vấn (thường chứa các chi tiết nhạy cảm nhất) và một số chi tiết trong tiêu đề; trình duyệt biết một số thông tin tiêu đề (loại nội dung, unicode, v.v.); và lịch sử trình duyệt, quản lý mật khẩu, mục yêu thích / dấu trang và các trang được lưu trong bộ nhớ cache đều sẽ chứa chuỗi truy vấn. Nhật ký máy chủ ở đầu xa cũng có thể chứa chuỗi truy vấn cũng như một số chi tiết nội dung.

Ngoài ra, URL không phải lúc nào cũng an toàn: tên miền, giao thức và cổng hiển thị - nếu không các bộ định tuyến không biết gửi yêu cầu của bạn ở đâu.

Ngoài ra, nếu bạn đã có proxy HTTP, máy chủ proxy sẽ biết địa chỉ, thông thường họ không biết chuỗi truy vấn đầy đủ.

Vì vậy, nếu dữ liệu đang di chuyển, nó thường được bảo vệ. Nếu nó không quá cảnh, nó không được mã hóa.

Không chọn nit, nhưng dữ liệu ở cuối cũng được giải mã và có thể được phân tích cú pháp, đọc, lưu, chuyển tiếp hoặc loại bỏ theo ý muốn. Và, phần mềm độc hại ở hai đầu có thể chụp nhanh dữ liệu nhập (hoặc thoát) giao thức SSL - chẳng hạn như Javascript (xấu) bên trong một trang bên trong HTTPS, có thể lén lút thực hiện các cuộc gọi http (hoặc https) đến các trang web ghi nhật ký (kể từ khi truy cập vào ổ cứng cục bộ thường bị hạn chế và không hữu ích).

Ngoài ra, cookie cũng không được mã hóa theo giao thức HTTPS. Các nhà phát triển muốn lưu trữ dữ liệu nhạy cảm trong cookie (hoặc bất kỳ nơi nào khác cho vấn đề đó) cần sử dụng cơ chế mã hóa của riêng họ.

Đối với bộ đệm, hầu hết các trình duyệt hiện đại sẽ không lưu các trang HTTPS, nhưng thực tế đó không được xác định bởi giao thức HTTPS, nó hoàn toàn phụ thuộc vào nhà phát triển trình duyệt để đảm bảo không lưu các trang bộ đệm nhận được thông qua HTTPS.

Vì vậy, nếu bạn lo lắng về việc đánh hơi gói tin, có lẽ bạn vẫn ổn. Nhưng nếu bạn lo lắng về phần mềm độc hại hoặc ai đó chọc vào lịch sử, dấu trang, cookie hoặc bộ nhớ cache của bạn, bạn vẫn chưa ra khỏi nước.

— Andrew Jennings
nguồn

20

Tôi biết các câu trả lời tốt được đặt lên hàng đầu, nhưng điều này một lần nữa chèn thông tin bị lỗi . Tên miền không hiển thị, trừ khi SNI được sử dụng. Giao thức, ngoài IP và TCP không hiển thị. Bạn không thể biết nếu tôi đang sử dụng HTTP 1.1, SPDY hoặc HTTP2. Những gì có thể nhìn thấy trên hai điểm cuối là không liên quan, vì mục tiêu của mã hóa không phải là làm cho mọi thứ trở nên vô hình mà là làm cho mọi thứ chỉ hiển thị cho các bên đáng tin cậy. Vì vậy, các điểm cuối được ngụ ý trong câu hỏi và khoảng 2/3 câu trả lời của bạn có thể được gỡ bỏ. Thông tin proxy phải là: nếu bạn sử dụng proxy HTTPS, thì nó có quyền truy cập vào mọi thứ .

— Melvyn

6

Liên kết của bạn nói cụ thể rằng cookie được mã hóa: "Kết nối của khách truy cập được mã hóa, che khuất URL, cookie và siêu dữ liệu nhạy cảm khác."

— DylanYoung

1

Vâng, đó là chính xác. Cookies được mã hóa trong khi quá cảnh, nhưng một khi chúng truy cập trình duyệt, chúng không được mã hóa bởi giao thức SSL. Nhà phát triển có thể mã hóa dữ liệu cookie, nhưng điều đó nằm ngoài phạm vi của SSL.

— Andrew Jennings

4

@DylanYoung SSL = lớp ổ cắm an toàn ; TLS = bảo mật lớp vận chuyển . Mã hóa ở cấp độ ổ cắm (kết nối) hoặc đặt nó theo một cách khác ở cấp độ vận chuyển không được lưu trữ trong trình duyệt trên mỗi cơ sở dữ liệu tên miền.

— tò mò

@Wigwam Cookie HTTP nhạy cảm về bảo mật hầu như luôn là các tham chiếu mờ (thường là số ngẫu nhiên mạnh về mặt mật mã) đối với bản ghi trong cơ sở dữ liệu máy chủ của các phiên xác thực. Vì việc mã hóa như vậy, định danh vô nghĩa này chủ yếu sẽ mang lại sự phức tạp bổ sung.

— tò mò

53

Phiên bản HTTP 1.1 đã thêm một phương thức HTTP đặc biệt, CONNECT - nhằm tạo đường hầm SSL, bao gồm bắt tay giao thức cần thiết và thiết lập mật mã.
Các yêu cầu thường xuyên sau đó tất cả được gửi được bọc trong đường hầm SSL, bao gồm các tiêu đề và cơ thể.

— AviD
nguồn

Khi nào CONNECT được sử dụng để tạo đường hầm SSL?

— tò mò

@curiousguy tools.ietf.org/html/rfc7231#section-4.3.6

— avp

47

Với SSL, mã hóa ở mức vận chuyển, vì vậy nó diễn ra trước khi yêu cầu được gửi.

Vì vậy, mọi thứ trong yêu cầu đều được mã hóa.

— thổi
nguồn

Vì SSL diễn ra trong lớp vận chuyển và việc gán địa chỉ đích trong các gói (trong tiêu đề) diễn ra trong lớp mạng (nằm dưới mức vận chuyển), vậy các tiêu đề được mã hóa như thế nào?

— Prateek Joshi

@PrateekJoshi Bởi vì các tiêu đề HTTP sống trên lớp ứng dụng và theo mặc định, được mã hóa do lớp thấp hơn / tổ tiên được mã hóa.

— Aquarelle

40

HTTPS (HTTP qua SSL) gửi tất cả nội dung HTTP qua đường dẫn SSL, do đó, nội dung và tiêu đề HTTP cũng được mã hóa.

— CMS
nguồn

21

Có, tiêu đề được mã hóa. Nó được viết ở đây .

Mọi thứ trong thông điệp HTTPS đều được mã hóa, bao gồm các tiêu đề và tải yêu cầu / phản hồi.

— nhấn phím
nguồn

37

Wikipedia không phải là thông số kỹ thuật, đó là những gì bạn nên trích dẫn.

— Aran Mulholland

8

URL cũng được mã hóa, bạn thực sự chỉ có IP, Cổng và nếu SNI, tên máy chủ không được mã hóa.

— xxiao
nguồn

Ngay cả khi SNI không được hỗ trợ, một trung gian có khả năng chặn các kết nối HTTP cũng sẽ thường có khả năng giám sát các câu hỏi DNS (hầu hết việc chặn được thực hiện gần máy khách, như trên bộ định tuyến người dùng lậu). Vì vậy, họ sẽ có thể nhìn thấy tên DNS.

— tò mò