như anh bên trên nói thì em hiểu nó như 1 cái web server ấy, nhưng cái web này chỉ có nhiệm vụ trung chuyển request như cái trạm xe buýt, nhưng ai biết được proxy này nó có lưu dữ liệu vào db hay ko, vì là server thông thường nên nó toàn quyền xử lý dữ liệu như web sever rồi.
Proxy có khả năng lưu dữ liệu từ client gửi lên không?
1 Like
nếu dùng https thì proxy ko thể đọc đc dữ liệu trong payload, https sinh ra để chống lại mấy dạng mitm này mà, nó chỉ lưu được thông tin ko thuộc payload, và ko được mã hóa thôi
5 Likes
Bạn có thể giải thích rõ hơn không, vì sao proxy không đọc được?
5 Likes
thì như mình nói đó https ra đời để chống lại trò nghe lén, client và server sẽ thiết lập quá trình bắt tay với nhau và sau khi bắt tay thành công thì mọi dữ liệu truyền đi sẽ bị mã hóa, bạn có thể lên google tìm về ssl để hiểu rõ hơn, à mà nếu chính client cho phép kẻ thứ 3 nghe lén thì mới nghe lén đc, thường điều này chỉ xảy ra khi bạn làm việc cho các cty, mà các cty đó ép buộc bạn phải sài mạng của họ máy của họ để làm việc, còn hiện tại thì chả có cách nào bẻ khóa trực tiếp 1 giao thức https để nghe lén cả, ngay cả nhà mạng, ISP cũng ko thể nghe lén đc
Vậy là trong mô hình client-server, proxy đóng vai trò là client đúng không?
nó chỉ là 1 đường ống trung gian để dữ liệu chạy ngang qua, nó ko phải là client mà cũng chả phải server, nó chỉ là server khi bạn biến nó thành server
vd: client c-1 muốn kết nối đến server s-1 thông qua proxy p-1, (giả sử dùng Forward proxy), lúc này địa chỉ đích mà c-1 gửi đi vẫn là s-1, nhưng nơi gửi đi sẽ là p-1 chứ ko phải c-1, thành ra tại s-1 sẽ thấy nơi gửi đi là p-1 , trong trường hợp này p-1 chỉ là nơi trung gian để gửi request đi và nhận response về nó ko thể đọc được payload
còn nếu ta tạo ra 1 server để cân bằng tải chẳng hạn, thì lúc này client c-1 sẻ gửi request thẳng đến server cân bằng tải s-1, rồi tại s-1 này sẽ đọc dữ liệu tính toán blabla để quyết định chuyển tiếp request này đến đâu, lúc này s-1 mới đọc được request
và nói chung là , thằng nào cầm được private key thì thằng đó mới đọc được dữ liệu , còn lại trăm ngàn thằng cướp giữa đường chỉ nhìn đống data như là 1 mớ binary code thôi
Tìm hiểu Man in middle attack nhé. Đơn giản là proxy relay lại connection của bạn với bên cung cấp thì theo bạn có thể nghe lén được không
3 Likes
tôi hay bạn mới cần xem lại? kiểm chứng dễ nhất nhé, bạn làm dev chắc quá quen với mấy công cụ test rồi chứ nhỉ, bạn có thể thử bất cứ công cụ nào chặn bắt gói tin , như wireshark,Burp Suite ,charles xem thử bạn đọc đc gói tin ssl ko nhé 
, man in middle attack gặp ssl là tắt điện chứ ở đó mà nghe lén
bạn đang so sánh proxy với những tool bắt gói tin như wireshark?
bạn có hiểu relay connection là gì không?
bạn nói ssl mã hoá, vậy hỏi lại, mã hoá bằng key gì, mã hoá như nào, key ở đâu ra? và quan trọng hơn, key mà bạn trao đổi, hay handshake lúc đầu có đi qua proxy không?
3 Likes
Đây là proxy. Không phải trò bắt gói tin. Bằng 1 cách nào đó lừa trình duyệt tin rằng chứng chỉ mà proxy cung cấp là chứng chỉ đích thì hoàn toàn có thể relay yêu cầu từ người dùng tới server đích. Lúc đó thì server proxy làm gì với dữ liệu của bạn thì có trời mới biết
4 Likes
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ì ?
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?