سؤالات متداول برای تمایل فنی

این سؤالات متداول در مورد MTPROTO برای کاربران پیشرفته در نظر گرفته شده است. همچنین ممکن است بخواهید سؤالات متداول اصلی ما را بررسی کنید. توجه داشته باشید که توسعه دهندگان مشتری موظفند دستورالعمل های امنیتی را رعایت کنند.

• چرا از پروتکل سفارشی استفاده کردید؟
• چگونه کار می کند؟
• رمزگذاری سرور
• رمزگذاری پایان به پایان
• چرا از راه حل دیگری استفاده نکردید؟
• چرا بیشتر به الگوریتم های رمزنگاری کلاسیک تکیه می کنید؟
• من یک متخصص امنیتی هستم و در مورد راه اندازی شما نظر دارم

• چگونه پیام های mtproto تأیید می شوند؟
• آیا از رمزگذاری و MAC استفاده می کنید؟
• چرا به دنبال رمزگذاری نیستید- سپس-بعد؟
• آیا هنوز از sha-1 استفاده می کنید؟
• آیا از IGE استفاده می کنید؟IgE شکسته است!

• چگونه سرور در طول تبادل کلید DH تأیید می شود؟
• مشتریان چگونه تأیید می شوند؟
• چت های مخفی چگونه تأیید می شوند؟
• تماس های صوتی و تصویری چگونه تأیید می شوند؟
• آیا رازداری رو به جلو دارید؟

• حملات شناخته شده-متن
• حملات انتخاب شده
• حملات انتخاب شده-Ciphertext
• در مورد IND CCA چطور؟
• حملات پخش مجدد
• حملات انسان در وسط
• برخورد هش برای کلیدهای DH
• حملات پسوند طول

• چرا از CDN استفاده می کنید؟
• آیا CDN می تواند پرونده ای را رمزگشایی کند؟
• آیا CDN ها می توانند فایلهای خود را با نسخه های خاص خود جایگزین کنند؟
• آیا می توان از CDN برای سانسور استفاده کرد؟
• آیا می توانم این را تأیید کنم؟
• آیا این بر داده های خصوصی تأثیر می گذارد؟
• آیا این به درخواست های دولت برای انتقال سرورها به قلمرو خود مرتبط است؟
• آیا این امر به کشورها تأثیر بر تلگرام می دهد؟

سوالات عمومی

س: چرا برای پروتکل سفارشی رفتید؟

به منظور دستیابی به قابلیت اطمینان در اتصالات ضعیف تلفن همراه و همچنین سرعت هنگام برخورد با پرونده های بزرگ (مانند عکس ها ، فیلم های بزرگ و پرونده های حداکثر 2 گیگابایت) ، MTProto از یک رویکرد اصلی استفاده می کند. این سند برای روشن شدن جزئیات خاص از راه اندازی ما و همچنین پرداختن به برخی از نکات مهم که ممکن است در نگاه اول نادیده گرفته شود ، در نظر گرفته شده است.

س: از کجا می توانم درباره پروتکل بیشتر بخوانم؟

مستندات دقیق پروتکل در اینجا موجود است. لطفاً توجه داشته باشید که MtProto از دو لایه پشتیبانی می کند: رمزگذاری مشتری-سرور که در چت های ابری تلگرام و رمزگذاری پایان به پایان استفاده می شود که در چت های مخفی تلگرام استفاده می شود. برای اطلاعات بیشتر قسمت زیر را ببینید.

اگر نظری دارید ، احساس راحتی کنید تا به امنیت@telegram. org مراجعه کنید

س: چگونه رمزگذاری سرور-مشتری در MTProto کار می کند؟

رمزگذاری سرور-مشتری در چت های ابری تلگرام استفاده می شود. در اینجا مختصراً از تنظیمات آورده شده است:

یادداشت 1

هر پیام ساده که باید در mtproto رمزگذاری شود ، همیشه حاوی داده های زیر است که باید در هنگام رمزگشایی بررسی شود تا سیستم در برابر مشکلات شناخته شده با مؤلفه ها قوی شود:

• نمک سرور (64 بیتی)
• شناسه جلسه
• شماره توالی پیام
• طول پیام
• زمان

توجه 2

نظرات اضافی در مورد استفاده ما از IGE و تأیید اعتبار پیام را مشاهده کنید.

نکته 3

چت های مخفی رمزگذاری شده پایان به تلگرام از یک لایه اضافی رمزگذاری در بالای توضیحات بالا استفاده می کنند.

س: رمزگذاری پایان به پایان در MTProto چگونه کار می کند؟

رمزگذاری پایان به پایان در چت های مخفی تلگرام و همچنین تماس های صوتی و تصویری استفاده می شود. می توانید اطلاعات بیشتر در مورد آن را در اینجا بخوانید: چت های مخفی ، رمزگذاری پایان به پایان. در اینجا مختصراً از تنظیمات آورده شده است:

لطفاً برای جزئیات بیشتر به این مقالات مراجعه کنید:

• چت های مخفی ، رمزگذاری پایان به پایان
• طرح TL پایان به پایان
• شماره های توالی در گپ های مخفی
• رازداری کامل رو به جلو
• تماس های صوتی رمزگذاری شده پایان به پایان

س: چرا از X استفاده نمی کنید؟(درج راه حل)

در حالی که بدون شک روش های دیگر برای دستیابی به همان اهداف رمزنگاری وجود دارد ، احساس می کنیم که راه حل فعلی هم قوی است و هم در کار ثانویه ما در ضرب و شتم پیام رسان های رمزگذاری نشده از نظر زمان تحویل و ثبات ، موفقیت آمیز است.

س: چرا بیشتر به الگوریتم های رمزنگاری کلاسیک تکیه می کنید؟

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

نقاط ضعف چنین الگوریتم ها نیز مشهور است و برای چندین دهه مورد سوء استفاده قرار گرفته است. ما از این الگوریتم ها در چنین ترکیبی استفاده می کنیم که به بهترین دانش ما ، از حملات شناخته شده جلوگیری می کند.

س: من یک متخصص امنیتی هستم و در مورد راه اندازی شما نظر دارم.

تلگرام از توسعه دهندگان و جامعه تحقیقات امنیتی برای ممیزی خدمات ، کد و پروتکل خود به دنبال آسیب پذیری یا مسائل مربوط به امنیت استقبال می کند. برای یادگیری چگونگی گزارش یافته های خود ، از برنامه رسمی Bounty ما دیدن کنید.

لطفاً توجه داشته باشید که ما نمی توانیم قبل از پرداختن به آنها ، برای موضوعاتی که در معرض دید عموم قرار می گیرند ، ارائه دهیم.

رمز

س: چگونه پیام های mtproto تأیید می شوند؟

تمام برنامه های تلگرام اطمینان می دهند که MSG_KEY برابر با SHA-256 از قطعه ای از Auth_Key است که با پیام رمزگشایی شده (از جمله 12… 1024 بایت بالشتک تصادفی) همراه است. این مهم است که Plaintext همیشه شامل طول پیام ، نمک سرور ، Session_ID و سایر داده های شناخته شده برای مهاجم باشد.

بسیار مهم است که کلیدهای رمزگشایی AES هم به msg_key بستگی داشته باشد و هم به auth_key ، که فقط به طرفین درگیر در مبادله شناخته می شود.

س: آیا شما در حال انجام رمزگذاری-سپس-مك ، Mac-then-endpt یا mac و رمزگذاری هستید؟

ما هیچکدام از موارد فوق را انجام نمی دهیم. برای احراز هویت پیام ، ما Sha-256 (auth_key_fragment + aes_decrypt (… ، رمزگذاری شده_مسژ)) را پس از دریافت پیام محاسبه می کنیم و این مقدار را با msg_key دریافت شده با پیام رمزگذاری شده مقایسه می کنیم.

س: چرا شما به دنبال یک رویکرد استاندارد رمزگذاری شده پس از آن نیستید؟

با استفاده از Encrypt-Then-Mac ، به عنوان مثالدرگیر GCM (حالت پیشخوان Galois) ، طرف دریافت کننده را قادر می سازد تا رمزهای غیرمجاز یا اصلاح شده را تشخیص دهد ، بنابراین نیاز به رمزگشایی آنها را در صورت دستکاری از بین می برد.

در mtproto ، مشتری ها و سرور با اطمینان از اینکه SHA-256 (auth_key_fragment + plaintext + padding) = msg_key و اینکه این متن همیشه حاوی طول پیام ، نمک سرور ، Session_ID و سایر داده هایی است که قبل از پذیرش هر یک از مهاجم بالقوه شناخته نشده است ، پیام های تأیید می کنند. پیاماین بررسی های امنیتی انجام شده بر روی مشتری قبل از پذیرش هر پیام ، اطمینان حاصل کنید که پیام های نامعتبر یا دستکاری شده با پیام های همیشه با خیال راحت (و ساکت) دور می شوند.

به این ترتیب به همان نتیجه می رسیم. تفاوت در این است که بررسی امنیتی قبل از رمزگشایی در رمزگذاری-بعد از ظهر و بعد از رمزگشایی در mtproto انجام می شود-اما در هر صورت قبل از پذیرش پیام. رمزگذاری / رمزگشایی AES در دستگاه های موجود در حال استفاده از نظر سرعت با محاسبه اضافی HMAC مورد نیاز برای رویکرد رمزگذاری-سپس-بعد قابل مقایسه است.

س: آیا هنوز از SHA-1 استفاده می کنید؟

نسخه فعلی پروتکل با استفاده از SHA-256 است. Mtproto 1. 0 برای تکیه بر SHA-1 استفاده می شد (برای جزئیات بیشتر به این سؤالات متداول مراجعه کنید).

در Mtproto 2. 0 ، SHA-1 فقط در جایی استفاده می شود که انتخاب عملکرد هش برای امنیت بی ربط است ، به عنوان مثال:

• هنگام تولید کلیدهای جدید
• برای محاسبه 64 بیتی auth_key_id از auth_key
• برای محاسبه 64 بیتی key_fingerprint در چت مخفی که برای بررسی های سلامت استفاده می شود (اینها تجسم کلیدی نیستند-آنها از الگوریتم دیگری استفاده می کنند ، به برخورد هش برای کلیدهای متفاوتی مراجعه کنید)

س: آیا از IGE استفاده می کنید؟IgE شکسته است!

بله ، ما از IGE استفاده می کنیم ، اما در اجرای ما شکسته نشده است. این واقعیت که ما از IgE به عنوان MAC به همراه سایر خصوصیات سیستم ما استفاده نمی کنیم ، حملات شناخته شده به IgE را بی ربط نمی کند.

IgE ، دقیقاً همانطور که CBC همه گیر ، در برابر CPA سازگار با بلوک آسیب پذیر است. اما حملات تطبیقی فقط تهدیدی است تا زمانی که می توان از همان کلید در چندین پیام استفاده کرد (نه در MTProto).

حملات تطبیقی حتی از نظر تئوری در MTPROTO غیرممکن است ، زیرا برای رمزگذاری پیام باید ابتدا کاملاً تشکیل شود ، زیرا کلید به محتوای پیام بستگی دارد. در مورد CPA غیر سازگار ، IgE در برابر آنها ایمن است ، همانطور که CBC است.

احراز هویت

س: چگونه سرور در جریان تبادل کلید DH تأیید می شود؟

Exchange DH با کلید عمومی سرور که در مشتری ساخته شده است تأیید می شود (همان کلید RSA برای محافظت در برابر حملات MITM نیز استفاده می شود).

س: چگونه مشتریان تأیید می شوند؟

اسرار مختلف (nonce ، server_nonce ، new_nonce) در طول تولید کلیدی رد و بدل می شود که DH-Key را فقط با نمونه ای که مبادله را آغاز کرده است ، می توان بدست آورد.

توجه کنید که New_Nonce فقط یک بار ، در داخل یک پیام رمزگذاری شده RSA از مشتری به سرور منتقل می شود.

س: چت های مخفی چگونه تأیید می شوند؟

کلیدهای چت های مخفی رمزگذاری شده پایان به پایان توسط نمونه جدیدی از تبادل کلید DH تولید می شوند ، بنابراین آنها فقط به طرفین درگیر و نه به سرور شناخته می شوند. برای تعیین هویت این احزاب و اطمینان از عدم وجود MITM ، توصیه می شود که هویت ها را مقایسه کنید ، که از هش از کلیدهای چت مخفی DH تولید می شود (تجسم های کلیدی).

س: چگونه تماس های صوتی و تصویری تأیید می شوند؟

کلیدهای تماس های رمزگذاری شده پایان به پایان با استفاده از Exchange Key Diffie-Hellman ایجاد می شوند. کاربرانی که در حال تماس هستند می توانند با مقایسه تجسم های کلیدی ، MITM وجود نداشته باشند.

برای اینکه تأیید کلیدی در زمینه تماس صوتی عملی باشد ، تلگرام از اصلاح سه پیام از مبادله کلید استاندارد DH برای تماس ها استفاده می کند:

• A>B: (تولید A و) G_A_HASH را ارسال می کند: = Hash (G^a)
• B>پاسخ: (فروشگاه های g_a_hash ، تولید b و) g_b را ارسال می کند: = g^b
• A>ب: (کلید محاسبه می کند (g_b) a ، سپس) g_a را ارسال می کند: = g a
• ب: هش (g_a) را چک می کند == g_a_hash ، سپس کلید (g_a)^b را محاسبه می کند

ایده این است که آلیس به مقدار خاصی از A (و از G_A) متعهد می شود ، اما G_A را به باب (یا حوا) نشان نمی دهد تا آخرین مرحله. باب مجبور است بدون دانستن مقدار واقعی G_A ، ارزش B و G_B را انتخاب کند. اگر حوا در حال انجام یک حمله میانه در وسط است ، بسته به ارزش G_B دریافت شده از باب نمی تواند تغییر کند و همچنین بسته به G_A نمی تواند ارزش B را تنظیم کند. در نتیجه ، حوا فقط به یک شلیک می شود تا پارامترهای خود را تزریق کند - و او باید این شلیک را با چشمان بسته شلیک کند.

با تشکر از این اصلاح ، جلوگیری از استراق سمع (حملات MITM به DH) با احتمال بیش از 0. 9999999999 با استفاده از بیش از 33 بیت آنتروپی در تجسم امکان پذیر می شود. این بیت ها در قالب چهار شکلک به کاربران ارائه می شوند. ما استخر 333 ایموجی را انتخاب کرده ایم که همه کاملاً متفاوت از یکدیگر هستند و می توان به راحتی با کلمات ساده به هر زبانی توصیف کرد.

می توانید اطلاعات بیشتر در مورد تأیید کلید برای تماس های تلگرام را در اینجا بخوانید.

س: آیا رازداری رو به جلو دارید؟

محافظت در برابر حملات شناخته شده

حملات شناخته شده-متن

با تعریف ، حمله شناخته شده-پپنچ (KPA) یک الگوی حمله برای رمزنگاری است که در آن مهاجم نمونه هایی از متن ساده و نسخه رمزگذاری شده آن (Ciphertext) را دارد.

AES IGE که در mtproto استفاده می شود در برابر حملات KPA قوی است (این را ببینید ، اگر تعجب می کنید که چگونه می توان از IGE با اطمینان استفاده کرد). مهمتر از آن ، متن ساده در mtproto همیشه حاوی Server_salt و شناسه جلسه است.

حملات انتخاب شده

با تعریف ، یک حمله به صورت انتخابی (CPA) یک مدل حمله برای رمزنگاری است که فرض می کند که مهاجم توانایی انتخاب متن های دلخواه خود را برای رمزگذاری و به دست آوردن رمزهای مربوطه دارد.

Mtproto از AE در حالت IgE استفاده می کند (این را ببینید ، اگر تعجب می کنید که چگونه می توان از IGE با اطمینان استفاده کرد) که در برابر CPA های غیر سازگار ایمن است. IgE شناخته شده است که در برابر CPA سازگار با بلوک ایمن نیست ، اما Mtproto این کار را به روش زیر اصلاح می کند:

هر پیام ساده که باید رمزگذاری شود ، همیشه حاوی موارد زیر است که باید پس از رمزگشایی بررسی شود:

• نمک سرور (64 بیتی)
• شماره توالی پیام
• زمان

مهمتر از این ، برای جایگزینی متن ساده ، شما همچنین باید از کلید AES و IV مناسب استفاده کنید ، هر دو به Auth_Key وابسته هستند. این باعث می شود Mtproto در برابر CPA قوی باشد.

حملات انتخاب شده-Ciphertext

با تعریف ، یک حمله-سفیر انتخاب شده (CCA) یک مدل حمله برای رمزنگاری است که در آن رمزنگاری کننده اطلاعات ، حداقل تا حدودی ، با انتخاب یک رمزگذاری متن و به دست آوردن رمزگشایی آن تحت یک کلید ناشناخته جمع می کند. در این حمله ، یک دشمن این فرصت را دارد که یک یا چند رمزگذاری شناخته شده را به سیستم وارد کرده و متن های حاصل از آن را بدست آورد. از این اطلاعات ، دشمن می تواند برای بازیابی کلید مخفی پنهان مورد استفاده برای رمزگشایی تلاش کند.

هر بار که یک پیام در MTProto رمزگشایی می شود، بررسی می شود تا ببینیم آیا msg_key برابر با SHA-256 قطعه ای از auth_key است که با پیام رمزگشایی شده (شامل 12…1024 بایت بالشتک تصادفی) الحاق شده است. متن ساده (داده های رمزگشایی شده) همچنین همیشه حاوی طول پیام، نمک سرور و شماره ترتیب است. این CCA های شناخته شده را نفی می کند.

در مورد IND-CCA چطور؟

MTProto 2. 0 شرایط عدم تمایز تحت حمله متن رمزی انتخاب شده (IND-CCA) را برآورده می کند.

حملات پخش مجدد

حملات پخش مجدد رد می شوند زیرا هر متن ساده ای که باید رمزگذاری شود حاوی نمک سرور و شناسه پیام و شماره دنباله منحصر به فرد است.

این بدان معنی است که هر پیام فقط یک بار می تواند ارسال شود.

حملات انسان در وسط

تلگرام دو حالت ارتباطی دارد: چت معمولی با استفاده از رمزگذاری سرویس گیرنده-سرور و چت مخفی با استفاده از رمزگذاری سرتاسر.

ارتباط Client-Server از حملات MiTM در طول تولید کلید DH با استفاده از یک کلید عمومی RSA سرور تعبیه شده در نرم افزار مشتری محافظت می شود. پس از آن، اگر هر دو مشتری به نرم افزار سرور اعتماد کنند، گفتگوهای مخفی بین آنها توسط سرور در برابر حملات MiTM محافظت می شود.

این رابط راهی برای مقایسه کلیدهای چت مخفی برای کاربرانی که به سرور اعتماد ندارند ارائه می دهد. تجسم کلید به شکل یکسان ارائه شده است (به عنوان مثال در اینجا). با مقایسه تجسم های کلیدی، کاربران می توانند مطمئن شوند که هیچ حمله MITM صورت نگرفته است.

برخورد هش برای Diffie-Hellman Keys

در حال حاضر، اثر انگشت از 128 بیت SHA-1 به هم پیوسته با 160 بیت از کلید SHA-256 استفاده می کند که در مجموع 288 بیت اثر انگشت به دست می دهد، بنابراین احتمال حملات هش-برخورد را نفی می کند.

حملات پسوند طول

طبق تعریف، حملات پسوند طولی نوعی حمله هستند که از انواع خاصی از هش ها به عنوان کدهای احراز هویت پیام سوء استفاده می شود و امکان گنجاندن اطلاعات اضافی را فراهم می کند.

یک پیام در MTProto شامل یک msg_key است که برابر با SHA-256 قطعه ای از auth_key است که با متن ساده الحاق شده است (شامل 12…1024 بایت بالشتک تصادفی و برخی پارامترهای اضافی)، به دنبال آن متن رمزی. مهاجم نمی تواند بایت های اضافی را به انتها اضافه کند و SHA-256 را مجدداً محاسبه کند، زیرا SHA-256 از روی متن ساده محاسبه می شود، نه متن رمز، و مهاجم هیچ راهی برای به دست آوردن متن رمز متناظر با بایت های متن ساده اضافی که ممکن است بخواهد ندارد. برای اضافه کردن.

جدا از آن ، تغییر MSG_KEY همچنین کلید رمزگشایی AES را برای پیام به گونه ای غیرقابل پیش بینی برای مهاجم تغییر می دهد ، بنابراین حتی پیشوند اصلی به زباله ها رمزگشایی می کند - که بلافاصله تشخیص داده می شود از آنجا که برنامه یک بررسی امنیتی را انجام می دهد تا اطمینان حاصل شودSHA-256 از متن ساده (همراه با قطعه ای از Auth_Key) با MSG_KEY دریافت شده مطابقت دارد.

CDN های رمزگذاری شده

از Telegram 4. 2 ، ما از CDN های رمزگذاری شده برای ذخیره رسانه ها از کانال های عمومی با بیش از 100000 عضو پشتیبانی می کنیم. گره های ذخیره CDN در مناطقی با ترافیک قابل توجه تلگرام واقع شده اند که ما نمی خواهیم به دلایل مختلف سرورهای تلگرام را قرار دهیم.

برای جزئیات فنی اجرای ، رمزگذاری و تأیید داده ها ، به کتابچه راهنمای CDN مراجعه کنید.

این سند را برای نسخه فارسی این سؤالات متداول مشاهده کنید. بوش فarsی

س: چرا تصمیم به استفاده از CDN گرفتید؟

ما از سرورهای توزیع شده خودمان برای سرعت بخشیدن به بارگیری در مناطقی که آزادی بیان تضمین شده است استفاده می کنیم - و حتی در آنجا ما این کار را به طور کامل انجام نمی دهیم. اما هنگامی که تلگرام در مناطق دیگر بسیار محبوب می شود ، ما فقط می توانیم به CDN هایی که مانند ISP ها از نظر فنی رفتار می کنیم ، اعتماد کنیم زیرا آنها فقط داده های رمزگذاری شده ای دریافت می کنند که نمی توانند رمزگشایی کنند.

به لطف این فناوری ، سرعت بارگیری برای عکس ها و فیلم های عمومی می تواند در مناطقی مانند ترکیه ، اندونزی ، آمریکای جنوبی ، هند ، ایران یا عراق بدون کوچکترین سازش در امنیت بیشتر شود.

س: آیا CDN می تواند پرونده ها را رمزگشایی کند؟

خیر. هر پرونده ای که به CDN ارسال می شود با یک کلید منحصر به فرد با استفاده از رمزگذاری AES-256-CTR رمزگذاری می شود. CDN نمی تواند به داده هایی که در آن ذخیره می کند دسترسی پیدا کند زیرا این کلیدها فقط برای سرور اصلی MTProto و مشتری مجاز قابل دسترسی هستند.

س: آیا CDN می تواند داده ها را با نسخه خود جایگزین کند؟

شماره. داده های بارگیری شده از گره های ذخیره CDN همیشه توسط برنامه دریافت تلگرام از طریق هش تأیید می شود: مهاجمان قادر به جایگزینی هر پرونده با نسخه های خاص خود نخواهند بود.

س: آیا CDN می تواند پرونده هایی را حذف کند؟

شماره CDN فقط نسخه های رمزگذاری شده حافظه نهان ، نسخه های اصلی در سرورهای تلگرام ذخیره می شوند. کاربر در مورد دریافت پرونده توسط سرور Telegram مطلع شده است. اگر گره ذخیره CDN پرونده را به کاربر ندهد ، کاربر مستقیماً از سرور Telegram پرونده را دریافت می کند.

س: آیا می توان از CDN برای سانسور استفاده کرد؟

نه. همه پرونده های اصلی در سرورهای تلگرام ذخیره می شوند. CDN ها فقط داده های رمزگذاری شده دریافت می کنند - و آنها نمی توانند آن را رمزگشایی کنند. آنها نمی توانند هیچ داده ای را جایگزین کنند. و در صورت بروز هرگونه مشکل در CDN ، این پرونده به سادگی از طریق سرورهای تلگرام به طور مستقیم به کاربران تحویل داده می شود. کاربران همیشه داده های خود را دریافت می کنند ، هیچ کس نمی تواند این کار را متوقف کند.

س: آیا می توانم این را تأیید کنم؟

آره. هرکسی می تواند با بررسی کد منبع برنامه های تلگرام و بازرسی از ترافیک ، اجرای CDN ما را تأیید کند.

س: آیا این بر داده های خصوصی تأثیر می گذارد؟

نه. گره های ذخیره CDN بخشی از ابر تلگرام نیستند. گره های ذخیره CDN فقط برای ذخیره رسانه های عمومی عمومی از کانال های عظیم استفاده می شود. داده های خصوصی هرگز به آنجا نمی روند.

س: آیا این با درخواست های دولت برای انتقال داده های خصوصی به قلمرو آنها مرتبط است؟

نه. ما با هیچ دولتی در مورد CDN ها توافق نکرده ایم و CDN ها بخشی از معامله نیستند. تنها هدف CDN ها بهبود ایمن اتصال در مناطق با تقاضای زیاد است که تلگرام نمی تواند سرورهای خود را قرار دهد.

س: آیا این امر به برخی از کشورها تأثیر بر تلگرام می دهد؟

نه. ما اقدامات احتیاطی ویژه ای را انجام داده ایم تا اطمینان حاصل کنیم که هیچ کشوری از طریق گره های ذخیره CDN هیچ اهرمی از طریق تلگرام به دست نمی آورد:

• CDN ها متعلق به تلگرام نیستند-همه خطرات مربوط به یک شرکت شخص ثالث است که گره های CDN را در سراسر جهان به ما عرضه می کند.
• ما در این CDN ها هیچ سرمایه گذاری نکردیم و فقط هزینه ترافیکی را که برای انتقال کالاهای ذخیره شده از خوشه های اصلی ما و به کاربران نهایی استفاده می شود ، پرداخت می کنیم.

در نتیجه ، اگر هر کشوری تصمیم بگیرد با CDN در منطقه خود دچار آشفتگی شود ، آنها به جز کاهش اتصال برای شهروندان خود چیزی به دست نمی آورند - و تلگرام هیچ چیز از ارزش خود را از دست نمی دهد.