bằng 1 cách nào đó? cách nào nhỉ, bạn là nhà cung cấp proxy mà bạn dám nói bằng 1 cách nào đó lừa? vậy nếu không có cách nào đó … 
thì bạn đọc được không , cái ssl tạo ra kiểu mã hóa dữ liệu dựa vào private key và public key mà bạn nói bằng 1 cách nào đó lừa , vậy thì khi bạn đố thằng trộm vào nhà bạn và đưa khóa nhà cho nó thì có ý nghĩa gì ?
Proxy có khả năng lưu dữ liệu từ client gửi lên không?
tôi đã nói bạn lên gg đọc về ssl và https đi rồi tự trả lời , private key luôn nằm ở server, ko có private key thì coi như ko đọc đc dữ liệu
không ai phủ nhận những gì bạn nói, chỉ có bạn là không nghe những gì người khác nói
bạn đánh đồng tool bắt gói tin với proxy => điều này chứng tỏ, mitm đối với bạn cũng chỉ là dùng tool bắt gói tin để đọc? nothing more?
private key ở server => đúng
client dùng public key để mã hoá => không sai
nhưng vấn đề là public key ở client là từ đâu mà ra?? ok, từ quá trình handshake trao đổi key với server
vậy vấn đề kế tiếp, quá trình handshake đó có đi qua proxy hay không?
nếu bạn chưa hiểu từ khoá “relay” của mitm là gì, thì cũng không cần reply lại đâu
-
client-proxy: ê proxy, gửi tin nhắn này đến server giúp tui “hello server, gửi cho tui cái public key của bạn”
-
proxy-to-server: “hello server, gửi cho tui cái public key của bạn”
-
server-to-proxy: “ok bạn, public key là server-public, sau này bạn có gửi gì cho tui thì nhớ dùng key nàt mã hoá”
-
proxy-client: server said: ông server trả lời bạn nè client “ok bạn, public key proxy-public, sau này bạn có gửi gì cho tui thì dùng key này để mã hoá”
-
client, oh yeah, có key rồi, 123456 mã hoá thành !@#%^, khỏi sợ thằng nào đọc được proxy ơi, gửi đên server cái này giúp tui "!@#%^,"
-
proxy, haha, để dùng cái “proxy-private” giải mã coi thằng client nó muốn gửi gì nào, à, thì ra pass của nó là 123456, ok, để dùng public key của thằng server mã hoá lại rồi gửi cho nó,
123456 mã hoá thành “)(*&&^%” -
proxy-to-server: “)(*&&^%”
à, thằng client gửi cho mình, để dùng “server private” của mình giải mã xem nào, thì ra là 123456
…
5 Likes
cmt vậy chứng tỏ cũng chưa đọc hết ssl, https rồi :D, giả mạo sao được khi cái CA bắt buộc phải được trust bởi client, hoặc là 1 bên thứ 3 có uy tín , khi gửi 1 CA giả mạo trình duyệt sẽ báo đỏ ngay, đọc cái gì cũng đọc cho rõ ngọn ngành, lý thuyết phải đi đôi với thực tế, ngồi đoán già đoán non trên cái nền sai thì ko đúng được đâu, mà tôi có nói nữa bạn cũng ko hiểu, tôi dám khẳng định luôn là client gửi dữ liệu đến server thông qua 1 proxy, mà proxy đó ko có được trust từ client thì không bao giờ nó đọc được dữ liệu cả
bây giờ bạn muốn thì tôi với bạn làm 1 cái thử nghiệm thôi, bạn tạo ra 1 proxy thần thánh gì đó của bạn đi, tôi dùng proxy đó rồi gửi dữ liệu đến 1 server thông qua https, và tôi sẽ ko trust bất kỳ certifi nào từ proxy xem có lấy đc dữ liệu ko …
video này khá dễ hiểu bạn xem đi rồi bớt suy luận linh tinh dùm
khi bạn đã kết nối đến vpn/proxy thì tất cả mọi giao tiếp của bạn đều đã thông qua người khác, bạn đã đồng ý để data của bạn đi qua tay người khác
và topic này đang thảo luận về việc vpn có khả năng đọc được hay không hay nếu có mở rộng hơn một tí thì là vì sao đọc được, đọc như thế nào
bạn khẳng định chắc nịt là không, chỉ cần ssl thì là không,
các ví dụ của bạn cũng chỉ xoay quanh những tool bắt gói tin, và mình có cảm giác như mitm đối với bạn cũng chỉ là bắt gói tin chứ chả có gì hơn
sau đó bạn qloved có nói với bạn về proxy relay, thì câu trả lời của bạn là ví dụ về những tool bắt gói tin, chắc chắn không liên quan tới proxy relay, nếu bạn biết concept về proxy relay thì bạn đã không reply vớ vẩn kiểu đó
nói về chứng chỉ giả, thì vẫn có thể giả được, ngừoi dùng muốn biết thật giả thì phải tự mà kiểu tra thông tin chứng chỉ, chứ còn vô tư lướt web không để ý gì thì sẽ không để ý
giả thì sao? nếu vẫn xài thì chết chứ sao
từ đầu tới cuối không ai cho rằng ssl và chứng chỉ là cái gì đó dễ dàng qua mặt, không ai phủ nhận tác dụng của chứng chỉ và ssl
tuy nhiên, khi bạn khẳng đi chắc chắn 100% an toàn bất chấp thì lại là câu chuyện khác, ngay từ ví dụ bạn nói bên trên, bạn làm việc cho cty, bạn phải sử dụng mạng của cty (không cần phải là dùng phần cứng) thì cũng đã đủ để bị ngừoi ta nghe lén rồi, và việc bạn sử dụng proxt/vpn của bên nào đó cũng tương tự
chỉ có bạn là học lý thuyết và chém gió (khẳng định chắc nít), chứ ở đây cũng chưa ai phủ nhận những gì của bạn nói cả
và đến giờ có vẻ như bạn cũng chỉ muốn mọi người công nhận những gì bạn nói/khẳng định, chứ còn đóng góp của người khác thì bạn cũng không kiểm chứng
trong topic này cũng không chỉ nói về http (trên trình duyệt có thể nhìn thất biểu tượng ổ khoá bị gạch thì mới biết, mà người dùng bình thường có thể bỏ qua)
chứ còn các giao thức khác, chạy giao tiếp ngầm, không có warning trên UI thì làm sao biết
cuối cùng thì topic cũng nên kết thúc ở đây, thấy bạn gửi cái link nên mình cũng muốn gửi lại một cái link
1 Like
à có thể bạn chưa biết thì tìm hiểu thêm về hsts đi, mà khi trình duyệt nó warning chứng chỉ giả, mà bạn vẫn chấp nhận truy cập, thì lúc đó kết nối đó ko còn là ssl nữa rồi, lúc đó thì chả cần phải proxy, tôi chỉ cần ngồi cùng mạng với bạn tôi cũng có thể lấy đc hết thông tin của bạn thông qua, trò ARP poisoning rồi
chỗ này tôi nói dùng đồ cty chính là nói đến việc, họ sẽ mặc định trust sẳn các CA và cài vào máy client, rồi khi đó người dùng truy cập ra ngoài thông qua proxy của họ thì proxy đó sẽ đẩy các CA đã đc trust về client và client chấp nhận nó vậy là đọc được dữ liệu, và vì bạn làm cho cty đó mọi dữ liệu bạn làm việc sẽ thuộc quyền sở hữu của họ nên bạn chẳng có quyền khiếu nại, còn chuyện bạn cài 1 cái proxy/vpn hoàn toàn ko giống vì sao ạ, vì chỉ cần tôi phát hiện ra nó lén cài thêm CA vào máy tôi để nghe lén tôi hoàn toàn có thể kiện nó
vì quan điểm của những cmt trên là qua mặt đc ssl mà ko nhắc gì đến việc bắt buộc phải trust CA, hoặc nếu có thì cũng nói kiểu “bằng cách nào đó lừa?”, nó sai hoàn toàn với mục đích chính của giao thức ssl đó là chống lại việc nghe lén, anh ko có CA được trust thì tôi ko bắt tay với anh, hoặc anh bắt tay thì đó là 1 kết nối ko an toàn ko đc trust và lúc đó kết nối của anh ko phải ssl
chạy ngầm thì nó vẫn phải thực hiện giao thức bắt tay ssl, và các ngôn ngữ lập trình đều có cơ chế để thông báo về chứng chỉ giả, và lúc đó nó cũng ép client trust cái CA đó ko thì khỏi chạy, và vì sao tôi biết điều này? vì tôi đã viết ứng dụng bằng cả nodejs,python, android để kết nối đến server có ssl, và nếu server đó trả về 1 CA ko được trust thì client reject nó ngay
à còn về cái link này, tôi muốn hỏi bạn 1 câu bạn đã dowload nó về và chạy thử chưa?
Chứng chỉ giả được tin là chứng chỉ thật và không hề có warning gì không phải là 1 cái gì đó không thể tạo ra được. Nếu như bạn đã quá rành về HTTPS chắc bạn cũng hiểu cách mà 1 chứng chỉ được coi là tin cậy. Ta sẽ chia ra làm 2 trường hợp:
TH1: máy bạn là máy thuộc tổ chức nội bộ và kết nối qua proxy của cty. Lúc này IT có thể can thiệp vào máy bạn chỉnh sửa root CA để proxy có thể luôn trình ra được chứng chỉ giả như thật cho mọi trang web. TH này quá lí tưởng nên bỏ qua không cần bàn sâu nữa
TH2: máy bạn là máy cá nhân kết nối qua 1 proxy độc hại, tạm coi là có thể đến từ anh hàng xóm. Lúc này bên cung cấp proxy hoặc lợi dụng lỗ hổng của 1 CA nào đó để issue ra 1 chứng chỉ giả cho 1 trang web mục tiêu cần nghe lén hoặc bản thân họ sẽ là 1 CA. Lúc này chứng chỉ đối với client vẫn là thật, proxy vẫn nghe lén như bình thường
PS: tôi không phủ nhận những dẫn chứng bạn nói là sai. Tuy nhiên phát biểu của bạn cho rằng “dùng HTTPS là 100% an toàn với mọi proxy” là 1 phát biểu ngây thơ, chỉ cần 1 TH sai là đã khiến phát biểu trên của bạn sai rồi.
3 Likes
cái mitm_relay đòi
In Windows, double-click on the cacert.cer file and choose to “Install certificate”, place it in the “Trusted root certification authorities” store.
trust cert của nó thì nó giả dạng CA được đúng rồi :V
để tạo khóa bảo mật cho cuộc hội thoại thì có Diffie Hellman key exchange - C có bắt được lá thư A/B gửi cho B/A cũng ko thể đọc được tin nhắn giữa A và B. Vấn đề còn lại chỉ là A có thể tin B là B được hay ko, hay là C giả dạng B. Cái này thì có certificate và để tin cert này thì có CA ký chứng nhận. Để biết CA là CA thì ko có cách nào khác là phải install/trust cert của CA :V Trust CA bậy bạ thì bị giả dạng, còn ko trust bậy bạ thì làm sao bị mitm giả dạng được :V
nếu proxy nó đòi trust cert của nó thì 100% là proxy lừa đảo. Còn ko thì trừ phi nó cướp được private key của 1 CA nào đó thì nó mới giả dạng được. Cũng có trường hợp “cướp” được rồi. “Cướp” ở đây có lẽ là chính phủ Mỹ cầm súng dí vào đầu mấy em JMicron và Realtek, bảo đưa key cho anh và 2 cty này đưa cho Mỹ tạo virus Stuxnet phá hoại chương trình làm giàu uranium của Iran :V Hoặc có thể Mỹ bỏ 100tr đô la xây siêu máy tính phân tích thừa số nguyên tố RSA hoặc lợi dụng 1 backdoor nào đó trong tiêu chuẩn ECDSA mà họ tự viết ra rồi :V Ba cái thiết kế chọn điểm khởi đầu trong elliptic curve cũng bí hiểm lắm. Backdoor lồ lộ thì mấy nước đối địch nó thấy hết, ko có backdoor thì ko nghe lén được :V Có lẽ backdoor này chỉ tận dụng được khi có siêu máy tính cỡ 100tr đô hay 1 tỷ đô. Ko chừng bitcoin là do mấy anh NSA tạo ra để giả dạng máy cày bitcoin nhưng khi thật ra là máy crack privkey đó 
à bữa nghe bên Mỹ internet mắc lắm, hỏi tại sao mắc thì bảo do mấy cty tham lam. Nhưng thật ra có thể là do chính phủ Mỹ buộc mấy cty đó phải lưu lại log truy cập của user trong vòng 5 năm, vì vậy tiền internet mới mắc
5 Likes
Cũng vì vụ này mà Google và Firefox cũng mấy lần cập nhật để loại bỏ root CA độc hại, nên việc proxy giả dạng không phải là không thể xảy ra. Phần lớn là sẽ có chính phủ hoặc tổ chức to chống lưng do đó chọn proxy để dùng cũng phải cẩn thận, nếu cẩn thận hơn nữa thì Pin certificate lại là chắc nhất.
Update link về mấy vụ này cho ae tham khảo
3 Likes
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?