این مقاله بخش دوم از قسمت ۱ چگونه یک TCP پراکسی بسازیم است.
چگونه یک TCP پراکسی بسازیم ؟
۲.۲.۱ – Burp چگونه درخواستها را مسیریابی میکند؟
Burp و سایر پراکسی‌های http/s با استفاده از یک سری ویژگی‌‌های خاص پروتکل http درخواستها را مسیریابی می‌کنند. در ادامه به این ویژگی‌ها نگاهی می‌اندازیم و اینکه چگونه این ویژگی‌ها در مسیریابی ترافیک http و https کمک می‌کنند.
HTTP
درخواست‌های HTTP/1.X شامل سرآيند Host هستند که بصورت واضح نام hostname که درخواست باید به آن ارسال شود را مشخص می‌کنند. درخواست‌های HTTP/2.X حاوی یک شبه سرآیند هستند که تقریبا همان اطلاعات را شامل می‌شوند. پراکسی‌های HTTP براحتی می‌توانند این اطلاعات را تجزیه تحلیل کنند، و بر این اساس درخواست را دوباره ارسال کنند.
HTTPS
دو نوع پراکسی https وجود دارد: پراکسی مرد میانی و دیگری پراکسی ارسال. پراکسی forwarding یا ارسال، داده‌های https را بدون رمزگشایی پراکسی میکند. این پراکسی قادر به خواندن سرآیند درخواستها نیست، به دلیل اینکه این سرایند دردرخواست‌های https رمزنگاری شده است. پس باید از راه دیگری استفاده کند.
پروتکل https با ارسال درخواست CONNECT اضافی که مختص پراکسی است، این مشکل را حل میکند. اگر کلاینت بداند که ترافیک https اش از یک پراکسی عبور خواهد کرد، یک درخواست جداگانه http connect برای پراکسی ارسال میکند.این درخواست در یک متن رمزنگاری نشده، نام میزبانی که ترافیک رمزنگاری شده باید به آن ارسال شوند را اعلام میکند. بدین صورت پراکسی نیازی به رمزگشایی برای پیدا کردن hostname ندارد.
نوع دوم پراکسی https، پراکسی مرد میانی است; همین که ما در حال ساخت آن هستیم. تفاوت این پراکسی با پروکسی forwarding در این است که پراکسی مرد میانی قادر به رمزگشایی و خواندن داده‌هایی که از آن عبور میکند است. این پراکسی درخواست را به میزبان همانطور ارسال میکند که پراکسی http انجام می‌دهد.
پراکسی مردمیانی معمولاترجیح می‌دهند از پراکسی forwarding تقیلد کنند و در صورت امکان از درخواست CONNECT استفاده کنند. این پراکسی‌ها تنها زمانی از سرایند host استفاده می‌کنند که کلاینت از پراکسی بودن آنها آگاه نباشد و درخواست CONNECT را ارسال نکند.
۲.۳ – صدور گواهی جعلی
خوشبختانه پروتکل TCP که می‌خواهیم آن را بررسی کنیم از رمزنگاری TLS استفاده میکند.
TLS که آن را با نام SSL نیز می‌شناسیم، شکلی از رمزنگاری است که توسط پروتکل https در جهت حفظ اطلاعات کاربران استفاده می‌شود. TLS فقط برای استفاده https نیست و پروتکل TCP نیز از آن استفاده میکند. این بدین دلیل است که TLSبه فرم داده‌ای که رمزنگاری میکند، اهمیتی نمی‌دهد، می‌تواند http, ftp, xml و هر نوع فرم دیگه‌ای باشد.
مشکل اصلی TLS که ما باید آن را حل کنیم این است که موبایل‌مان را ترغیب کنیم تا به پراکسی ما اعتماد کند. پس از اینکار، رمزگشایی داده‌هایی که از موبایل فرستاده می‌شوند، ساده خواهد بود.
۲.۳.۱ – گواهینامه TLS و مرجع صدور گواهینامه
موبایل هوشمند شما نسبت به دنیای خارج بی‌اعتماد است – و درست هم همین است. چگونه قرار است مطمئن شود که مقصدی که داده‌ها را به آن ارسال میکند، متعلق به کیست؟ رمزنگاری و امنیت داده‌ها چه اهمیتی دارد، اگر داده‌ها را به مقصد نادرست یا اشتباهی ارسال کند؟ رمزنگاری TLS پارانویای تلفن همراه را برطرف، و از طرف دیگر کار ما را سخت میکند. TLS نه تنها داده‌ها را رمزنگاری میکند، بلکه مطمئن می‌شود که به مقصد درستی ارسال می‌شوند.
ارتباط TLS با روندی به عنوان TLS handshake تائید می‌شود. در طی یک گفتگو کلاینت و سرور همدیگر را می‌شناسند و روی یک کلید برای رمزنگاری و برقراری ارتباط امن به توافق می‌رسند. موبایل هوشمند ما روند TLS handshake را تکمیل نمی‌کند، مگر اینکه بتوانیم هویت پراکسی خود را با ارائه یک گواهینامه معتبر TLS ثابت کنیم.
ما باید Common Name گواهینامه (نام فیلدی در گواهینامه) را روی نام میزبان تنظیم کنیم تا تلفن هوشمند فکر کند دارد با host صحبت میکند. این کار آسان است. همچنین باید گواهینامه TLS را با مرجع صدور گواهی دیجیتال یا CA -Root Certificate Authority- که موبایل هوشمند‌مان به آن اعتماد دارد امضا کنیم. این کار دشوارتر خواهد بود.
از آنجاییکه هیچ گواهی TLS واقعی و امضا شده توسط CA نداریم، قرار است CA جعلی خودمان را بسازیم. برای CA خودمان گواهی امضا ایجاد می‌کنیم و این گواهی را بعنوان root CA روی موبایل نصب می‌کنیم. این باعث می‌شود که موبایل هوشمند هم به CA ما و مهمتر به گواهینامه‌هایی که CA ما امضا میکند، اعتماد کند. بدین ترتیب هر زمان که موبایل از پراکسی‌مان درخواست handshake TLS داشته باشد، ما نام میزبانی که موبایل می‌خواهد با آن صحبت کند را بررسی خواهیم کرد. سپس بسرعت برای آن یک گواهی با امضای CA جعلی خودمان ایجاد می‌کنیم و به موبایل هوشمند ارائه می‌دهیم. موبایل گواهی و امضای آن را چک میکند، می‌بیند که توسط CA معتبری که در لیست دارد امضا شده و روند handshake را تکمیل میکند.
با ایجاد ارتباط TLS بین موبایل و پراکسی ما، بقیه سیستم مطابق برنامه کار خواهد کرد.
۳ -پروژه
این پروژه به سه بخش تقسیم شده است.در هر بخش نحوه ساخت یکی از سه جز این پراکسی شرح داده خواهد شد.
- یک سرور DNS جعلی برای فریب موبایل هوشمند تا ترافیک TCP را به پراکسی ما ارسال کند.
- یک سرور پراکسی برای مدیریت جریان داده بین موبایل و سرور از راه دور.
- یک مرجع صدور گواهی جعلی برای مدیریت رمزنگاری TLS بین موبایل و پراکسی.
پس از تکمیل هر سه بخش, یک TCP پراکسی خواهید داشت که از آن برای تجزیه و تحلیل پروتکل بر پایه TCP استفاده می‌کنید.
منیع: https://robertheaton.com/2018/08/31/how-to-build-a-tcp-proxy-1/
