Khi bạn NHẬN
https://encrypted.google.com/search?q=%s
Các %struy vấn được mã hóa? Hay chỉ là phản ứng? Nếu không, tại sao Google phải phục vụ nội dung công khai cũng bằng mã hóa?
Khi bạn NHẬN
https://encrypted.google.com/search?q=%s
Các %struy vấn được mã hóa? Hay chỉ là phản ứng? Nếu không, tại sao Google phải phục vụ nội dung công khai cũng bằng mã hóa?
Câu trả lời:
Toàn bộ yêu cầu được mã hóa, bao gồm URL và thậm chí cả lệnh ( GET). Điều duy nhất mà một bên can thiệp như máy chủ proxy có thể lượm lặt được là địa chỉ đích và cổng.
Tuy nhiên, lưu ý rằng gói Client Hello của bắt tay TLS có thể quảng cáo tên miền đủ điều kiện trong bản rõ thông qua tiện ích mở rộng SNI (cảm ơn @hafichuk), được sử dụng bởi tất cả các trình duyệt chính hiện đại, mặc dù một số chỉ trên các HĐH mới hơn.
EDIT: (Vì điều này chỉ mang lại cho tôi huy hiệu "Câu trả lời tốt", tôi đoán tôi nên trả lời toàn bộ câu hỏi.
Toàn bộ phản hồi cũng được mã hóa; proxy không thể chặn bất kỳ phần nào của nó.
Google phục vụ các tìm kiếm và nội dung khác qua https vì không phải tất cả đều là công khai và bạn cũng có thể muốn ẩn một số nội dung công khai khỏi MITM . Trong mọi trường hợp, tốt nhất là để Google tự trả lời .
Bản thân URL được mã hóa, vì vậy các tham số trong chuỗi truy vấn không di chuyển đơn giản trên toàn bộ dây.
Tuy nhiên, hãy nhớ rằng các URL bao gồm dữ liệu GET thường được máy chủ web ghi lại, trong khi dữ liệu POST hiếm khi được. Vì vậy, nếu bạn đang dự định làm một cái gì đó như thế /login/?username=john&password=doe, thì đừng; sử dụng POST thay thế.
HTTPS Thiết lập một cấu trúc SSL cơ bản trước khi bất kỳ dữ liệu HTTP nào được truyền. Điều này đảm bảo rằng tất cả dữ liệu URL (ngoại trừ tên máy chủ, được sử dụng để thiết lập kết nối) chỉ được mang trong kết nối được mã hóa này và được bảo vệ khỏi các cuộc tấn công trung gian giống như bất kỳ dữ liệu HTTPS nào.
Trên đây là một phần của câu trả lời RẤT toàn diện từ Câu trả lời của Google có tại đây:
http://answers.google.com/answers/threadview/id/758002.html#answer
Phần của URL sau khi tên máy chủ được gửi an toàn.
Ví dụ: https://somewhere.com/index.php?NAME=FIELD
Phần /index.php?NAME=FIELDđược mã hóa. Các somewhere.comkhông.
Mọi thứ đều được mã hóa, nhưng bạn cần nhớ rằng, truy vấn của bạn sẽ nằm trong nhật ký của máy chủ và sẽ có thể truy cập được với các máy phân tích nhật ký khác nhau, v.v. (thường không phải là trường hợp có yêu cầu POST).
Vâng, nó an toàn. SSL mã hóa mọi thứ.
Trích từ yêu cầu POST:
POST /foo HTTP/1.1
... some other headers
Trích từ yêu cầu GET:
GET /foo?a=b HTTP/1.1
... some other headers
Trong cả hai trường hợp, bất cứ điều gì được gửi trên ổ cắm đều được mã hóa. Việc khách hàng nhìn thấy các tham số trong trình duyệt của mình trong yêu cầu GET không có nghĩa là một người đàn ông ở giữa sẽ nhìn thấy điều tương tự.
Tôi vừa kết nối qua HTTPS đến một trang web và thông qua một loạt các tham số GET. Sau đó tôi đã sử dụng wireshark để đánh hơi mạng. Sử dụng HTTP, URL được gửi không được mã hóa, điều đó có nghĩa là tôi có thể dễ dàng thấy tất cả các tham số GET trong URL. Sử dụng HTTPS, mọi thứ đều được mã hóa và tôi thậm chí không thể thấy gói nào là lệnh GET, chứ đừng nói đến nội dung của nó!
SSL diễn ra trước khi phân tích cú pháp tiêu đề, điều này có nghĩa là:
Client creates Request
Request gets encrypted
Encrypted request gets transmitted to the Server
Server decrypts the Request
Request gets parsed
Yêu cầu trông giống như thế này (không thể nhớ cú pháp chính xác, nhưng điều này phải đủ gần):
GET /search?q=qwerty HTTP/1.1
Host: www.google.de
Đây cũng là lý do tại sao việc có Chứng chỉ SSL khác nhau cho một số máy chủ trên cùng một IP có vấn đề, Tên máy chủ được yêu cầu không được biết cho đến khi giải mã.
HTTP/1.1xuất hiện ở cuối dòng đầu tiên.
Yêu cầu GET được mã hóa khi sử dụng HTTPS - thực tế đây là lý do tại sao các trang web được bảo mật cần phải có một địa chỉ IP duy nhất - không có cách nào để có được tên máy chủ dự định (hoặc thư mục ảo) từ yêu cầu cho đến khi được giải mã.