آیا xTLS ناامن شده است ؟

سلام من در این مدت برای استفاده شخصی از trojan + xtls + ws + nginx+cdn استفاده میکردم . از نظر سرعت و ارتباط و اتصال هم مشکلی ندارم . ولی اخیرا وقتی از SagerNet میخواستم تست کنم پروفایل رو که بهش اضافه کردم Alert میده که xTLS ناامن هست و سریعا قابل شناسایی . مستنداتش رو که خوندم مدل Encryption ش شبیه به ssl هست ضمن این که خود trojan هم پکت ها رو شبیه سازی و کپسوله میکنه . پس چرا چند ابزار مثل SagerNet باید اخطار compromise بدن ؟ اصلا این پروتکل امکان داره شناسایی سریع داشته باشه یا جدیدا مشکل شناسایی داره ؟ دیدم که xTLS از پروژه v2ray حذف شده ولی در Project X داره توسعه داده میشه . یعنی یه اکیپ حذفش کردن کلا ! ولی اکیپ دوم دارن توسعه اش میدن . ضمنا دولوپرهای Project X هم اکثرا برای عبور از GFW خودشون پیشنهاد xtls+trojan جدیدا دارن که wrapper اصلیش vless باشه . کسی اطلاع بیشتری داره از این ؟

سلام ببخشید امکانش هست راهنمایی کنید که کدوم پروتکل ها دارن کار میکنن چون Trojan کانکت نمیشه vless +ws کار میکنه اگر لطفا راهنمایی کنید ممنون میشم

سلام. اساسا ابداع xtls‌ توسط تیم Project X انجام گرفت و مختص به VLESS بود. البته بعد‌ها سایر پروتکل‌ها هم شروع به استفاده از XTLS کردن.

رمزنگاری در دو مرحله اتفاق می‌افته.

۱. بین کلاینت و پروکسی سرور: این دقیقا اولین درخواستی است که به پروکسی سرور ارسال میشه. در این پکت چیز خاصی نیست. صرفا مشخص می‌کنه که کاربر تمایل داره به چه مقصدی بره و محتویات پیام‌اش چی هست. IP/domain+PORT+Path+Body

۲. تونل بین سرور مقصد و کلاینت: پروکسی سرور به محض اینکه درخواست رو دریافت می‌کنه یه تونل امن مستقیم ایجاد می‌کنه بین کلاینت و سرور مقصد. به این معنی که صرفا هر چی از کلاینت می‌گیره به مقصد پاس میده و برعکس.

حالا داستان رمزنگاری اینه:

۱. آیا لازم هست پیام اولیه بین کلاینت و پروکسی رمز بشه؟ اگه TLS یا XTLS‌ استفاده کنیم این تبادل پیام رمز میشه. ۲. آیا لازم هست ترافیک تونل بین کلاینت و سرور مقصد هم رمز بشه؟ پروژه XTLS میگه اگه این تونل بر بستر HTTPS‌ شکل گرفته دیگه ما لازم نیست مجددا رمز کنیمش. اما TLS میاد دوباره ترافیک HTTPS رو رمز می‌کنه. پس انتظار میره کمی XTLS حتی سریع‌تر باشه. اما هر دو امن هستند.

اخیرا بحث‌های جدیدی راجع به یک flow جدید برای XTLS هست به نام vision. آیا شما هم به این اشاره می‌کنید؟ امکانش هست لینک رو به اشتراک بگذارید؟

ممنون از پاسخ مبسوط . اگر از xTLS براساس websocket/tcp استفاده بشه بله ارتباط اولیه هم encryption نداره و الزاما فقط دیتا جهت برقراری تونل منتقل میشه ولی اگر از trojan استفاده بشه خود trojan مدل ارتباطیش حتی در اصطلاحا bootstrap اولیه هم capsulation داره و پکت ها obfuscate میشن پس من به طور کلی با این موضوع مشکلی ندارم . فقط اون اخطار compromise رو میخواستم دلیلش رو بدونم و چون اصلا جایی تو گیت هاب هم برای Sagernet پیدا نکردم که issue بزنم بپرسم ازشون گفتم شاید چیز خاصی در موردش هست که من اطلاع ندارم . در مورد این که ترافیک تونل هم باید رمزگزاری بشه یا نشه . tls میگه تونل https باید انکریپت بشه و xtls میگه نیازی به انکریپت نیست در حالی که اصولا این موضوع زمانی منجر به کشف در DPI داخل GFW خواهد شد که باز هم شما از websocket یا TCP استفاده کنی . یعنی ارتباط براساس http برقرار بشه . اگر بری سراغ trojan اون از شروع ارتباط capsulation داره . حتی میشد شما یه trojan لوکال داشته باشی بعد پکت trojan رو با tcp بفرستی بره بعد در مقصد با tcp بگیری و بدیش به یک trojan لوکال دیگه در مقصد . اینجوری سرعت به شدت افزایش خواهد داشت ولی این کار cpu intensive هست . ( اینو همینطوری گفتم ربطی به موضوع نداشت ) در هر حال موضوع قابل بحثی در مورد خود xtls اگر هم باشه به نظرم همین فقط مورد دومی هست که شما گفتید که اینم با trojan حل میشه .

ممنون از پاسخ مبسوط . اگر از xTLS براساس websocket/tcp استفاده بشه بله ارتباط اولیه هم encryption نداره و الزاما فقط دیتا جهت برقراری تونل منتقل میشه ولی اگر از trojan استفاده بشه خود trojan مدل ارتباطیش حتی در اصطلاحا bootstrap اولیه هم capsulation داره و پکت ها obfuscate میشن پس من به طور کلی با این موضوع مشکلی ندارم . فقط اون اخطار compromise رو میخواستم دلیلش رو بدونم و چون اصلا جایی تو گیت هاب هم برای Sagernet پیدا نکردم که issue بزنم بپرسم ازشون گفتم شاید چیز خاصی در موردش هست که من اطلاع ندارم . در مورد این که ترافیک تونل هم باید رمزگزاری بشه یا نشه . tls میگه تونل https باید انکریپت بشه و xtls میگه نیازی به انکریپت نیست در حالی که اصولا این موضوع زمانی منجر به کشف در DPI داخل GFW خواهد شد که باز هم شما از websocket یا TCP استفاده کنی . یعنی ارتباط براساس http برقرار بشه . اگر بری سراغ trojan اون از شروع ارتباط capsulation داره . حتی میشد شما یه trojan لوکال داشته باشی بعد پکت trojan رو با tcp بفرستی بره بعد در مقصد با tcp بگیری و بدیش به یک trojan لوکال دیگه در مقصد . اینجوری سرعت به شدت افزایش خواهد داشت ولی این کار cpu intensive هست . ( اینو همینطوری گفتم ربطی به موضوع نداشت ) در هر حال موضوع قابل بحثی در مورد خود xtls اگر هم باشه به نظرم همین فقط مورد دومی هست که شما گفتید که اینم با trojan حل میشه .

لطف میکنید بگید چطور تروجان و ws , ngnix, رو باهم داشتید؟ در XRAY وقتی تروجان انتخاب میکنم گزینه ترنزمیت وجود نداره که ws انتخاب کنم

ممنون از پاسخ مبسوط . اگر از xTLS براساس websocket/tcp استفاده بشه بله ارتباط اولیه هم encryption نداره و الزاما فقط دیتا جهت برقراری تونل منتقل میشه ولی اگر از trojan استفاده بشه خود trojan مدل ارتباطیش حتی در اصطلاحا bootstrap اولیه هم capsulation داره و پکت ها obfuscate میشن پس من به طور کلی با این موضوع مشکلی ندارم . فقط اون اخطار compromise رو میخواستم دلیلش رو بدونم و چون اصلا جایی تو گیت هاب هم برای Sagernet پیدا نکردم که issue بزنم بپرسم ازشون گفتم شاید چیز خاصی در موردش هست که من اطلاع ندارم . در مورد این که ترافیک تونل هم باید رمزگزاری بشه یا نشه . tls میگه تونل https باید انکریپت بشه و xtls میگه نیازی به انکریپت نیست در حالی که اصولا این موضوع زمانی منجر به کشف در DPI داخل GFW خواهد شد که باز هم شما از websocket یا TCP استفاده کنی . یعنی ارتباط براساس http برقرار بشه . اگر بری سراغ trojan اون از شروع ارتباط capsulation داره . حتی میشد شما یه trojan لوکال داشته باشی بعد پکت trojan رو با tcp بفرستی بره بعد در مقصد با tcp بگیری و بدیش به یک trojan لوکال دیگه در مقصد . اینجوری سرعت به شدت افزایش خواهد داشت ولی این کار cpu intensive هست . ( اینو همینطوری گفتم ربطی به موضوع نداشت ) در هر حال موضوع قابل بحثی در مورد خود xtls اگر هم باشه به نظرم همین فقط مورد دومی هست که شما گفتید که اینم با trojan حل میشه .

لطف میکنید بگید چطور تروجان و ws , ngnix, رو باهم داشتید؟ در XRAY وقتی تروجان انتخاب میکنم گزینه ترنزمیت وجود نداره که ws انتخاب کنم

من از پنل های آماده استفاده نمیکنم . یک تونل شخصی هست که با command-line لینوکس و یک فایل config از نوع json استفاده میشه . اگر میخواین اون فایل config رو میتونم share کنم تنظیماتش رو براساس سرور خودتون اعمال کنین و تست کنین ولی لازم هست سمت trojan server ش هم تنظیمات مربوط به کانکشن های ws xTls رو اعمال کرده باشید .( فک کنم به صورت پیش فرض انجام میده اون نسخه ای که من ازش استفاده میکنم )

ممنون از پاسخ مبسوط . اگر از xTLS براساس websocket/tcp استفاده بشه بله ارتباط اولیه هم encryption نداره و الزاما فقط دیتا جهت برقراری تونل منتقل میشه ولی اگر از trojan استفاده بشه خود trojan مدل ارتباطیش حتی در اصطلاحا bootstrap اولیه هم capsulation داره و پکت ها obfuscate میشن پس من به طور کلی با این موضوع مشکلی ندارم . فقط اون اخطار compromise رو میخواستم دلیلش رو بدونم و چون اصلا جایی تو گیت هاب هم برای Sagernet پیدا نکردم که issue بزنم بپرسم ازشون گفتم شاید چیز خاصی در موردش هست که من اطلاع ندارم . در مورد این که ترافیک تونل هم باید رمزگزاری بشه یا نشه . tls میگه تونل https باید انکریپت بشه و xtls میگه نیازی به انکریپت نیست در حالی که اصولا این موضوع زمانی منجر به کشف در DPI داخل GFW خواهد شد که باز هم شما از websocket یا TCP استفاده کنی . یعنی ارتباط براساس http برقرار بشه . اگر بری سراغ trojan اون از شروع ارتباط capsulation داره . حتی میشد شما یه trojan لوکال داشته باشی بعد پکت trojan رو با tcp بفرستی بره بعد در مقصد با tcp بگیری و بدیش به یک trojan لوکال دیگه در مقصد . اینجوری سرعت به شدت افزایش خواهد داشت ولی این کار cpu intensive هست . ( اینو همینطوری گفتم ربطی به موضوع نداشت ) در هر حال موضوع قابل بحثی در مورد خود xtls اگر هم باشه به نظرم همین فقط مورد دومی هست که شما گفتید که اینم با trojan حل میشه .

لطف میکنید بگید چطور تروجان و ws , ngnix, رو باهم داشتید؟ در XRAY وقتی تروجان انتخاب میکنم گزینه ترنزمیت وجود نداره که ws انتخاب کنم

من از پنل های آماده استفاده نمیکنم . یک تونل شخصی هست که با command-line لینوکس و یک فایل config از نوع json استفاده میشه . اگر میخواین اون فایل config رو میتونم share کنم تنظیماتش رو براساس سرور خودتون اعمال کنین و تست کنین ولی لازم هست سمت trojan server ش هم تنظیمات مربوط به کانکشن های ws xTls رو اعمال کرده باشید .( فک کنم به صورت پیش فرض انجام میده اون نسخه ای که من ازش استفاده میکنم )

خیلی ممنون از جوابتون متاسفانه من علمشو ندارم که بتونم این رو انجام بدم اگر به نظرتون میتونم ممنون میشم شیر کنید من مطابق همین روش هایی که نوشتن دوستان اینجا جلو رفتم همه مسیرو در همین حد بلدم بازم ممنون

سلام. اساسا ابداع xtls‌ توسط تیم Project X انجام گرفت و مختص به VLESS بود. البته بعد‌ها سایر پروتکل‌ها هم شروع به استفاده از XTLS کردن.

رمزنگاری در دو مرحله اتفاق می‌افته.

۱. بین کلاینت و پروکسی سرور: این دقیقا اولین درخواستی است که به پروکسی سرور ارسال میشه. در این پکت چیز خاصی نیست. صرفا مشخص می‌کنه که کاربر تمایل داره به چه مقصدی بره و محتویات پیام‌اش چی هست. IP/domain+PORT+Path+Body

۲. تونل بین سرور مقصد و کلاینت: پروکسی سرور به محض اینکه درخواست رو دریافت می‌کنه یه تونل امن مستقیم ایجاد می‌کنه بین کلاینت و سرور مقصد. به این معنی که صرفا هر چی از کلاینت می‌گیره به مقصد پاس میده و برعکس.

حالا داستان رمزنگاری اینه:

۱. آیا لازم هست پیام اولیه بین کلاینت و پروکسی رمز بشه؟ اگه TLS یا XTLS‌ استفاده کنیم این تبادل پیام رمز میشه. ۲. آیا لازم هست ترافیک تونل بین کلاینت و سرور مقصد هم رمز بشه؟ پروژه XTLS میگه اگه این تونل بر بستر HTTPS‌ شکل گرفته دیگه ما لازم نیست مجددا رمز کنیمش. اما TLS میاد دوباره ترافیک HTTPS رو رمز می‌کنه. پس انتظار میره کمی XTLS حتی سریع‌تر باشه. اما هر دو امن هستند.

اخیرا بحث‌های جدیدی راجع به یک flow جدید برای XTLS هست به نام vision. آیا شما هم به این اشاره می‌کنید؟ امکانش هست لینک رو به اشتراک بگذارید؟

من یه چیزای جدیدی در مورد xTLS خوندم و این Vision رو هم که گفتین دیدم . خوف کردم ! این در مورد منطق اولیه خود xTLS بوده . The core logic of XTLS is to use real TLS to hide proxy traffic among the most common traffic on the Internet. منطق اصلی XTLS استفاده از TLS واقعی برای پنهان کردن ترافیک پروکسی در میان رایج ترین ترافیک اینترنت است.

این vision در واقع یک مدل TLS Encryption داخل تونل TLS هست !! خود xTLS اینجوریه که اول میاد یه تانل TLS میزنه بین مصرف کننده (!!) و یک پروکسی سرور به صورت عادی . بعد که تانل برقرار شد ترافیک اون نرم افزاری که میخواد از تانل استفاده کنه رو از این مسیر رد میکنه . حالا مشکل این بوده که این ترافیک دوم وقتی از داخل تانل میخواسته رد بشه چون خود تانل TLS بوده دیگه Encrypt نمیشده . اومدن یه flow به xTLS اضافه کردن به اسم xtls-rprx-vision که اگر اینو تو کانفیگ داشته باشین موقعی که کلاینت تانل اول رو میزنه و اپلیکیشن میخواد ترافیک رو از تانل اول رد کنه باز دوباره میاد اون ترافیک رو encrypt میکنه اینجوری GFW DPI حتی در صورتی که Encryption رو بتونه آنالیز کنه فقط پکت های لایه اول رو میتونه در بیاره و ترافیک دوم عین این میمونه که شما روی یک تانل مثلا ssh زده باشید . ارتباط دوم رو نمیتونه آنالیز کنه . خیلی عجیب بود ولی خوب . البته چون دو لایه رمزگذاری داره باعث میشه مصرف cpu خصوصا سمت سرور پروکسی بیشتر بشه خصوصا اونایی که مثلا ip اختصاصی میدن به هر vpn که certificate ش هم جداست . seakfind-vision-example https://github.com/XTLS/Xray-core/discussions/1295

با این چیز ها به نظرم نه تنها خود xTLS الان نا امن نیست بلکه با vision امنیت بهتری هم نسبت به tls داره .

سلام ممنون از به اشتراک گذاری. اما اتفاقا کاری که vision می کنه اینه تلاش می کنه تونل رو مجددا رمزنگاری نکنه. در مستندات مشخصا ذکر شده که اگه ترافیک تونل مبتنی بر TLS 1.3 هست، کلن بی خیال رمزنگاری بشه. این عدم رمزنگاری اتفاقا ترافیک رو شبیه تر به ترافیک عادی می کنه.

iranxray / hope

آیا xTLS ناامن شده است ؟ #32