Vì sao mitmproxy có thể đọc inspect được tất cả domain có ssl

#1

mình thắc mắc vì sao thằng https://mitmproxy.org/ có thể giải mã đc packet ssl của tất cả domain nhỉ, vì mình từng thử cài 1 web server https khi tạo private key và CA thì nó bắt phải khai báo subjectAltName , các domain nào khai được khai báo trong này thì sau này mình dùng domain này truy cập về web server mình nó mới ko bị báo lỗi CA chứ nhỉ
vd: mình test trên máy localhost
sửa file hosts :
192.168.1.10 test.local1
192.168.1.10 test.local2

tạo 1 web server https và add test.local1 vào subjectAltName

trust CA tương ứng với CA của web server https vừa tạo
dùng webbrowser truy cập vào test.local1 >> ok https ko báo lỗi
dùng webbrowser truy cập vào test.local2 >> https báo lỗi chứng chỉ không hợp lệ

sau đó mình add test.local2 vào subjectAltName >> rồi truy cập lại >> ok https ko báo lỗi

tuy nhiên thằng mitmproxy thì nó ko cần add subjectAltName nhưng nó vẫn bắt đc các packet ssl của web server https , chỉ cần mình trust CA của nó thôi

ko biết nó làm cách nào nhỉ

#2

thì từ test.localX --> browser browser nó có check SAN, còn thêm thằng mitm thì test.localX --> mitm --> browser ở bước test.localX --> mitm có lẽ thằng mitm nó ko check SAN, bước mitm --> browser thì browser trust CA của mitm rồi nên mitm nó giả dạng test.localX nó tạo cert có SAN của test.localX vào, browser check SAN của cert giả này ok thông qua. Cả 2 bước đều thông qua nên truy cập được :V

  • test.localX --cert[trusted CA ký, invalid SAN]–> mitm: ok, mitm ko check SAN
  • mitm --cert[mitm CA ký, valid SAN]–> browser: browser check SAN ok, do đã trust mitm CA nên cert này ok nốt
5 Likes
#3

nếu như vậy thì ko lẽ mỗi khi có 1 request đến thằng mitm lại xem thử domain đó là gì rồi add domain name vào SAN à

#4

One of the big limitations of vanilla TLS is that each certificate requires its own IP address. This means that you couldn’t do virtual hosting where multiple domains with independent certificates share the same IP address. In a world with a rapidly shrinking IPv4 address pool this is a problem, and we have a solution in the form of the Server Name Indication extension to the TLS protocols. This lets the client specify the remote server name at the start of the TLS handshake, which then lets the server select the right certificate to complete the process.

SNI breaks our upstream certificate sniffing process, because when we connect without using SNI, we get served a default certificate that may have nothing to do with the certificate expected by the client. The solution is another tricky complication to the client connection process. After the client connects, we allow the TLS handshake to continue until just after the SNI value has been passed to us. Now we can pause the conversation, and initiate an upstream connection using the correct SNI value, which then serves us the correct upstream certificate, from which we can extract the expected CN and SANs

đoạn này có nghĩa là gì nhỉ @@

#5

nó tạo cert chứa domain name đó 1 lần cho mỗi domain truy cập rồi lưu lại cert đó để lần truy cập sau xài lại chứ :V

SNI là extension cho TLS protocol :V Khi client connect tới IP của server thì bình thường mặc định là IP này tương ứng với 1 hostname/domain name duy nhất. Nhưng 1 server có thể serve nhiều website ở các domain khác nhau, nên mới đẻ ra cái SNI này để làm điều đó. Với SNI thì cho phép làm điều này, với điều kiện là client phải đưa thêm hostname khi connect tới IP của server đó. Đoạn tiếp theo là cách mà thằng mitm này implement quá trình nghe lén của nó thông qua SNI TLS này thôi :V

TLS mới còn có encrypted SNI nữa :V Mệt cho thằng mitmproxy nó implement thôi =]]

ví dụ A muốn connect tới trang abc.xyz thì trước tiên nó nhờ DNS tra xem IP của abc.xyz là gì, ví dụ là 123.234.345.456, nó sẽ connect tới 123.234.345.456. TLS có SNI thì A phải đưa thêm hostname là abc.xyz cho 123.234.345.456. Nhà cung cấp mạng ISP nếu ghi log lại sẽ thấy tài khoản A connect tới 123.234.345.456, và SNI là abc.xyz, vậy ISP sẽ biết A có truy cập vào trang abc.xyz vào thời điểm nào, download dung lượng bao nhiêu :V Muốn ISP ko thấy được thì phải encrypt cả SNI này, khi encrypt SNI thì trong log của ISP chỉ thấy A truy cập tới 123.234.345.456, mà IP này có thể là của rất nhiều trang khác nên ko biết A truy cập tới trang nào. Tuy nhiên vẫn có thể xem log của DNS được =] xem trước khi truy cập tới 123.234.345.456, A đã yêu cầu DNS resolve hostname nào ra được IP này. Vì vậy muốn ISP ko biết được truy cập trang nào thì A còn cần phải xài TLS cho DNS nữa =]

4 Likes
#6

Explicit HTTPS

  1. The client makes a connection to mitmproxy, and issues an HTTP CONNECT request.
  2. Mitmproxy responds with a 200 Connection Established , as if it has set up the CONNECT pipe.
  3. The client believes it’s talking to the remote server, and initiates the TLS connection. It uses SNI to indicate the hostname it is connecting to.
  4. Mitmproxy connects to the server, and establishes a TLS connection using the SNI hostname indicated by the client.
  5. The server responds with the matching certificate, which contains the CN and SAN values needed to generate the interception certificate.
  6. Mitmproxy generates the interception cert, and continues the client TLS handshake paused in step 3.
  7. The client sends the request over the established TLS connection.
  8. Mitmproxy passes the request on to the server over the TLS connection initiated in step 4

theo như giải thích của nó thì ở bước 6 dựa vào cái SAN values từ real server mà nó sẽ tạo ra 1 cái cert tương ứng, chỗ này có phải chính là nó add SAN vào cert của nó, xong nó quay ra nói chuyện với thằng client , lúc này thằng client so khớp cái SNI của nó với đám SAN và tiếp tục việc bắt tay phải ko nhỉ, vậy mỗi lần xuất hiện 1 domain mới ko có trong SAN hiện tại là nó phải tạo 1 cert mới phải ko nhỉ

#7

ừa :V ko tạo thì làm sao giả dạng :V
tạo cert cũng nhanh lắm, chắc ko tới nửa giây đâu

3 Likes
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?