📌 Summary
The SNI spoofing implementation appears to work on some networks (e.g. mobile/CGNAT-style connections), but fails or becomes unstable on fiber connections or any connection if it doesn't got enough high delay or jitter.
On fiber, TLS handshake may partially succeed, but the connection quickly degrades into heavy TCP retransmissions, duplicate ACKs, and spurious retransmission loops, eventually breaking the session.
🧪 Observed behavior
On affected networks:
-
TLS ClientHello is successfully modified with spoofed SNI
-
TLS handshake sometimes completes (Server Hello received)
-
Immediately after handshake:
- Heavy TCP retransmissions begin
- Duplicate ACK storms appear
- “Spurious retransmission” warnings in Wireshark
-
Multiple parallel connection attempts also fail (SYN retransmissions to various endpoints)
-
Some connections reset (RST, ACK)
-
DNS sometimes resolves to unexpected/internal IP ranges (suggesting possible interception or resolver manipulation or DNS highjack)
📊 Key patterns seen in capture
[TCP Retransmission] repeated across multiple flows[TCP Spurious Retransmission] after TLS handshake success[TCP Dup ACK] increasing over time- TLS
Application Data retransmitted or not acknowledged properly
- Mixed success across different CDN endpoints (Cloudflare, Akamai, Microsoft)
🔍 Working condition vs failing condition
Works (observed on mobile networks especially Irancell):
- SNI spoofing passes
- TLS handshake completes
- Session remains stable long enough for application traffic
Fails (observed on fiber networks):
- Handshake may succeed
- Session rapidly enters retransmission loops
- Connection becomes unstable or resets
🧠 Hypothesis
The issue is likely not pure SNI spoofing failure, but:
- TCP stream instability after packet modification
- Improper handling of fragmented TLS ClientHello across TCP segments
- Possible packet timing / re-injection issues under low-latency networks (fiber exposes race conditions more clearly than high-latency networks)
- Potential interaction with ISP-level DNS interception or traffic filtering on fiber connections
⚠️ Important note
The same behavior appears significantly more stable on higher-latency networks, suggesting that timing and TCP stream reassembly sensitivity plays a major role in failure conditions.
📎 Impact
- Inconsistent behavior across ISPs
- Breaks under low-latency/high-throughput conditions
- Makes SNI spoofing unreliable in production-like fiber environments
🧩 Request
It would be helpful to clarify:
- Expected safe method for modifying TLS ClientHello without breaking TCP stream consistency
- Whether current implementation assumes single-packet TLS ClientHello (vs fragmented TCP reassembly)
- Recommended handling for reinjection to avoid sequence/ACK desynchronization
🐛 باگ: جعل SNI در برخی شبکهها کار میکند اما در فیبر نوری دچار مشکل میشود (ارسال مجدد TCP + ناپایداری جریان)
📌 خلاصه
به نظر میرسد پیادهسازی جعل SNI در برخی شبکهها (مثلاً اتصالات موبایل/CGNAT-style) کار میکند، اما در اتصالات فیبر نوری یا هر اتصالی که تأخیر یا لرزش کافی نداشته باشد، با شکست مواجه میشود یا ناپایدار میشود.
در فیبر نوری، دستدهی TLS ممکن است تا حدی موفقیتآمیز باشد، اما اتصال به سرعت به ارسال مجدد سنگین TCP، ACK های تکراری و حلقههای ارسال مجدد جعلی تبدیل میشود و در نهایت جلسه را قطع میکند.
🧪 رفتار مشاهده شده
در شبکههای آسیبدیده:
-
TLS ClientHello با موفقیت با SNI جعلی اصلاح میشود
-
گاهی اوقات دستدهی TLS کامل میشود (Server Hello دریافت شد)
-
بلافاصله پس از دستدهی:
-
شروع ارسالهای مجدد سنگین TCP
-
طوفانهای تکراری ACK ظاهر میشوند
-
هشدارهای "ارسال مجدد جعلی" در Wireshark
-
چندین تلاش برای اتصال موازی نیز با شکست مواجه میشوند (ارسالهای مجدد SYN به نقاط انتهایی مختلف)
-
برخی از اتصالات بازنشانی میشوند (RST، ACK)
-
DNS گاهی اوقات به محدودههای IP غیرمنتظره/داخلی تبدیل میشود (نشان میدهد که ممکن است رهگیری یا دستکاری حلکننده یا DNS highjack انجام شود)
📊 الگوهای کلیدی مشاهده شده در ضبط
[ارسال مجدد TCP] در چندین جریان تکرار میشود[ارسال مجدد TCP جعلی] پس از موفقیت دستدهی TLS[TCP Dup ACK] با گذشت زمان افزایش مییابد- دادههای برنامه TLS دوباره ارسال شده یا به درستی تأیید نشدهاند
- موفقیتهای مختلف در نقاط پایانی CDN مختلف (Cloudflare، Akamai، Microsoft)
🔍 شرایط کار در مقابل شرایط شکست
کار میکند (در شبکههای تلفن همراه به ویژه ایرانسل مشاهده شده است):
- عبور از جعل SNI
- تکمیل دستدهی TLS
- جلسه به اندازه کافی برای ترافیک برنامه پایدار میماند
شکست میخورد (در شبکههای فیبر مشاهده شده است):
- دستدهی ممکن است موفق شود
- جلسه به سرعت وارد حلقههای ارسال مجدد میشود
- اتصال ناپایدار میشود یا تنظیم مجدد میشود
🧠 فرضیه
احتمالاً مشکل صرفاً نقص جعل SNI نیست، بلکه:
- ناپایداری جریان TCP پس از تغییر بسته
- مدیریت نادرست TLS ClientHello تکهتکه شده در بخشهای TCP
- مشکلات احتمالی زمانبندی/تزریق مجدد بسته در شبکههای با تأخیر کم (فیبر شرایط رقابتی را واضحتر از شبکههای با تأخیر بالا نشان میدهد)
- تعامل بالقوه با رهگیری DNS در سطح ISP یا فیلتر کردن ترافیک در اتصالات فیبر نوری
⚠️ نکته مهم
همین رفتار در شبکههای با تأخیر بالاتر به طور قابل توجهی پایدارتر به نظر میرسد، که نشان میدهد زمانبندی و حساسیت به مونتاژ مجدد جریان TCP نقش عمدهای در شرایط خرابی دارند.
--
📎 تأثیر
- رفتار متناقض در بین ISPها
- خرابی در شرایط تأخیر کم/توان عملیاتی بالا
- جعل SNI را در محیطهای فیبر نوری شبیه به محیط عملیاتی غیرقابل اعتماد میکند
🧩 درخواست
توضیح موارد زیر مفید خواهد بود:
- روش ایمن مورد انتظار برای تغییر TLS ClientHello بدون شکستن سازگاری جریان TCP
- اینکه آیا پیادهسازی فعلی TLS ClientHello تک بستهای را در نظر میگیرد (در مقابل مونتاژ مجدد TCP تکهتکه شده)
- نحوهی مدیریت تزریق مجدد برای جلوگیری از ناهمگامسازی توالی/ACK
📌 Summary
The SNI spoofing implementation appears to work on some networks (e.g. mobile/CGNAT-style connections), but fails or becomes unstable on fiber connections or any connection if it doesn't got enough high delay or jitter.
On fiber, TLS handshake may partially succeed, but the connection quickly degrades into heavy TCP retransmissions, duplicate ACKs, and spurious retransmission loops, eventually breaking the session.
🧪 Observed behavior
On affected networks:
TLS ClientHello is successfully modified with spoofed SNI
TLS handshake sometimes completes (Server Hello received)
Immediately after handshake:
Multiple parallel connection attempts also fail (SYN retransmissions to various endpoints)
Some connections reset (
RST, ACK)DNS sometimes resolves to unexpected/internal IP ranges (suggesting possible interception or resolver manipulation or DNS highjack)
📊 Key patterns seen in capture
[TCP Retransmission]repeated across multiple flows[TCP Spurious Retransmission]after TLS handshake success[TCP Dup ACK]increasing over timeApplication Dataretransmitted or not acknowledged properly🔍 Working condition vs failing condition
Works (observed on mobile networks especially Irancell):
Fails (observed on fiber networks):
🧠 Hypothesis
The issue is likely not pure SNI spoofing failure, but:
The same behavior appears significantly more stable on higher-latency networks, suggesting that timing and TCP stream reassembly sensitivity plays a major role in failure conditions.
📎 Impact
🧩 Request
It would be helpful to clarify:
🐛 باگ: جعل SNI در برخی شبکهها کار میکند اما در فیبر نوری دچار مشکل میشود (ارسال مجدد TCP + ناپایداری جریان)
📌 خلاصه
به نظر میرسد پیادهسازی جعل SNI در برخی شبکهها (مثلاً اتصالات موبایل/CGNAT-style) کار میکند، اما در اتصالات فیبر نوری یا هر اتصالی که تأخیر یا لرزش کافی نداشته باشد، با شکست مواجه میشود یا ناپایدار میشود.
در فیبر نوری، دستدهی TLS ممکن است تا حدی موفقیتآمیز باشد، اما اتصال به سرعت به ارسال مجدد سنگین TCP، ACK های تکراری و حلقههای ارسال مجدد جعلی تبدیل میشود و در نهایت جلسه را قطع میکند.
🧪 رفتار مشاهده شده
در شبکههای آسیبدیده:
TLS ClientHello با موفقیت با SNI جعلی اصلاح میشود
گاهی اوقات دستدهی TLS کامل میشود (Server Hello دریافت شد)
بلافاصله پس از دستدهی:
شروع ارسالهای مجدد سنگین TCP
طوفانهای تکراری ACK ظاهر میشوند
هشدارهای "ارسال مجدد جعلی" در Wireshark
چندین تلاش برای اتصال موازی نیز با شکست مواجه میشوند (ارسالهای مجدد SYN به نقاط انتهایی مختلف)
برخی از اتصالات بازنشانی میشوند (
RST، ACK)DNS گاهی اوقات به محدودههای IP غیرمنتظره/داخلی تبدیل میشود (نشان میدهد که ممکن است رهگیری یا دستکاری حلکننده یا DNS highjack انجام شود)
📊 الگوهای کلیدی مشاهده شده در ضبط
[ارسال مجدد TCP]در چندین جریان تکرار میشود[ارسال مجدد TCP جعلی]پس از موفقیت دستدهی TLS[TCP Dup ACK]با گذشت زمان افزایش مییابد🔍 شرایط کار در مقابل شرایط شکست
کار میکند (در شبکههای تلفن همراه به ویژه ایرانسل مشاهده شده است):
شکست میخورد (در شبکههای فیبر مشاهده شده است):
🧠 فرضیه
احتمالاً مشکل صرفاً نقص جعل SNI نیست، بلکه:
همین رفتار در شبکههای با تأخیر بالاتر به طور قابل توجهی پایدارتر به نظر میرسد، که نشان میدهد زمانبندی و حساسیت به مونتاژ مجدد جریان TCP نقش عمدهای در شرایط خرابی دارند.
--
📎 تأثیر
🧩 درخواست
توضیح موارد زیر مفید خواهد بود: