Lưu lượng https trên mạng không dây không được mã hóa có an toàn không?

21

Đây là điều mà tôi đã tự hỏi trong một thời gian dài. Nếu tôi, giả sử, sử dụng Gmail qua https, ai đó có thể đọc các cuộc hội thoại và email IM của tôi nếu tôi sử dụng mạng không dây không bảo mật không? Tôi giả định rằng dữ liệu sẽ được bảo mật, vì nó đang sử dụng kết nối được mã hóa. Có điều gì khác để xem xét?

wireless-networking security encryption

— davidscolgan
nguồn

3

Bài viết phải đọc liên quan: Firesheep

— Sathyajith Bhat

1

Tôi nghĩ rằng đó là bài báo đã thúc đẩy anh ấy / cô ấy hỏi một câu hỏi như vậy về chủ đề này.

— JFW

21

Tôi sẽ nghĩ rằng ai đó vẫn có thể thực hiện một cuộc tấn công trung gian nếu bạn đang sử dụng wifi không bảo mật (hoặc thậm chí là wifi được bảo mật, nếu họ tình cờ tìm được cách cho phép). Đây là lý do tại sao bạn cần luôn kiểm tra xem kết nối SSL có hiển thị màu xanh lục trong thanh địa chỉ của bạn không và / hoặc kiểm tra kỹ xem chứng chỉ có hợp lệ khi sử dụng wifi không bảo mật hay không. Giả sử rằng chứng chỉ là chính xác, thì SSL sẽ bảo vệ dữ liệu của bạn.

— Android Darth
nguồn

7

nếu SSL thực sự được mã hóa với các chứng chỉ SSL không bị xâm phạm được kiểm tra đúng cách thì cuộc tấn công MITM là không thể.

— ewanm89

@ ewanm89 Đó là lý do tại sao tôi lặp lại rằng người ta cần kiểm tra chứng chỉ khi làm ngân hàng / email / bất cứ điều gì nhạy cảm trên các mạng không bảo mật. Nếu bạn không nhận thấy rằng chứng chỉ không xác thực, MITM là có thể. May mắn thay, những người làm web ngày nay rất khó để không chú ý.

— Darth Android

1

Để thêm vào @ ewanm89, không thể là gói MITM và đánh hơi các gói - chỉ không thể đọc chúng vì chúng được mã hóa.

Được rồi, đó là chia tóc. MITM và có một gói trông giống như dữ liệu ngẫu nhiên cũng vô nghĩa như không thực hiện nó ở vị trí đầu tiên trong hầu hết các trường hợp. Nhưng vâng, người ta có thể theo dõi miền nào máy tính cũng đang kết nối, nhưng không biết dữ liệu thực tế được gửi / nhận. Ngoài ra, nếu chúng ta sẽ hoàn toàn trung thực, về mặt lý thuyết, tôi có thể buộc các phím AES có đủ sức mạnh tính toán (gợi ý nó cần rất nhiều).

— ewanm89

Ngoài ra, tôi cho rằng CA không bị xâm phạm, một kiểm tra rằng CA mà các quản trị viên trang thực tế đã đến CA đó và hỏi các quản trị viên rằng dấu vân tay của chứng chỉ phải là gì bởi một kênh khác. Như mọi người có thể thấy, việc kiểm tra đúng chứng chỉ SSL là rất hiếm (mặc dù được thực hiện trong các ứng dụng như openvpn nơi quản trị viên phân phối các certs trước khi kết nối, khách hàng cũng hoàn toàn xác minh nó).

— ewanm89

2

Tôi nghĩ rằng lý luận của bạn là chính xác; để đọc thông tin của bạn, họ sẽ cần giải mã SSL. Sẽ chỉ có một mức mã hóa ít hơn để chúng phá vỡ, để truy cập dữ liệu được mã hóa.

— Peter
nguồn

2

Miễn là DNS và máy chủ gốc SSL của trình duyệt của bạn hợp lệ, thì kẻ tấn công trên cùng một mạng không dây không an toàn vì bạn không thể truy cập vào đường ống SSL của mình bằng máy chủ.

DNS là lỗ hổng lớn trong lĩnh vực này - nếu chuỗi máy chủ DNS của bạn bị kẻ tấn công lây nhiễm hơn có thể khiến mọi thứ có vẻ an toàn nhưng thực tế lại không an toàn.

Nhưng nếu câu hỏi của bạn là liệu một hacker ngẫu nhiên tại sân bay hoặc quán cà phê sẽ có thể hack vào đường ống SSL của bạn đến ngân hàng của bạn hay không, thì câu trả lời gần như chắc chắn là không.

— stevemidgley
nguồn

1

Dù sao đi nữa, chỉ có dữ liệu bên trong luồng http được mã hóa nhưng URL thì không, vì vậy có lẽ ai đó có thể mạo danh bạn.

— Ignacio Soler Garcia
nguồn

2

Đơn giản là nó sai. Mọi thứ trong URL được yêu cầu ngoại trừ tên miền được mã hóa trước khi được gửi qua kết nối được bảo mật. Điều đó bao gồm chính yêu cầu GET.

— Andrew

1

Bạn cũng cần xem xét rằng các trang không SSL ban đầu không được bảo vệ.

Hầu hết các trang web được bảo mật mà bạn truy cập sẽ chuyển hướng bạn từ một http đến url https khi bạn truy cập trang đăng nhập, nhưng trên một mạng không đáng tin cậy, bạn có thể được gửi đến một người khác ở giữa.

Hãy xem xét rằng bạn có thể ghé thăm http://firstoverflowbank.com , mà thường sẽ chuyển hướng bạn đến https://login.firstoverflowbank.com nhưng trên mạng không an toàn được thiết lập thay vì gửi cho bạn để https://login.flrstoverflowbank.com thay . Bạn có thể sẽ không nhận thấy, ngay cả khi bạn dành thời gian để kiểm tra và trình duyệt sẽ hiển thị mọi thứ là an toàn.

Để tránh loại điều này, hãy đánh dấu hoặc nhập url https: // trực tiếp, không bao giờ dựa vào chuyển hướng đó.

— Andrew
nguồn