TLS – شناسه جلسه در اولین مشتری اول سلام

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

چرا این کار را می کند؟

آیا طبیعی است؟

آیا خطرات امنیتی وجود دارد؟

دستشویی – آیا استانداردهای TLS نیازمند اولویت سرور هستند تا همیشه در هنگام مذاکره با استفاده از رمزهای عبور استفاده شوند؟

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

این امر منطقی است، اما من را به تعجب می اندازد که چقدر این مورد بوده است و چرا گزینه هایی مانند: + SSL_OP_CIPHER_SERVER_PREFERENCE در openssl برای گزینه CTX وجود دارد: https://www.openssl.org/ docs / man1.0.2 / ssl / SSL_CTX_set_options.html

SSL_OP_CIPHER_SERVER_PREFERENCE

هنگام انتخاب یک رمزعبور، به جای ترجیحات مشتری، از تنظیمات سرور استفاده کنید. هنگامی که تنظیم نشده است، سرور SSL همیشه
  از ترجیحات مشتریان پیروی کنید. هنگام تنظیم، سرور SSLv3 / TLSv1 خواهد شد
  زیر تنظیمات خود را انتخاب کنید. از آنجا که متفاوت است
  پروتکل، برای SSLv2 سرور لیستی از ترجیحات خود را به آن ارسال می کند
  مشتری و مشتری انتخاب می کند

این معنی ندارد …

سوءاستفاده از SSL – در عمق جزئیات TLS / SSL طراحی شده است

پس از خواندن چند میلیون ثانیه اتصال HTTPS، من سعی می کنم بدانم چرا طراحی TLS / SSL به این صورت طراحی شده بود (به عنوان مثال، چرا ما به جای دو یک از دو کلید در TLS نیاز داریم و من MasterSecret را خوانده ام گسترش به کلید) و برخی از مقالات فنی مانند RFC6101، اما پس از آن متوجه شدم که من هنوز خرد بسیاری از عقل در پشت طراحی. با این حال، من قادر به پیدا کردن مقالات است که توضیح می دهند که چرا آنها باید به این شیوه طراحی (بیشتر مقاله من پیدا کردم فقط به من بگویید که آنها طراحی شده در این راه، زیرا آن را فراهم می کند "امنیت اضافی"، بدون ارائه "چرا" برای آن "امنیت فوق العاده".

خوب است اگر کسی بتواند طراحی TLS / SSL را به طور کلی (یا ارائه برخی پیشنهادات برای من برای حفاری) توضیح دهد، از جمله همه مکانهایی که مکانیسم های امنیتی استفاده می شود.

TLS – توضیحات مربوط به سایفر و اسکن Nmap

من دستور زیر Nmap را اجرا میکنم تا قدرت سوئیتهای سری که در میزبان من استفاده شده است را آزمایش کنم

 nmap -sV - script ssl-enum-ciphers -p 443 

Nmap doc می گوید هر ciphersuite با درجه نامه (A through F) نشان داده شده است که نشان دهنده قدرت اتصال است و خط خروجی از ابتدا شروع می شود. مقاومت کم نشان دهنده قدرت ضعیف ترین رمز شده است

وقتی که من فرمان را در برابر میزبان اجرا کردم، من خروجی را دریافت کردم همانطور که در زیر نشان داده شده است

 | ssl-enum-ciphers:
| TLSv1.0:
| رمزهای عبور:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 768) - E
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 768) - C
| TLS_DHE_RSA_WITH_DES_CBC_SHA (dh 768) - E
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| کمپرسورها:
| خالی
| اولویت رمز: مشتری
| هشدارها:
| بلوک بلوک 64 بیتی 3DES به حمله SWEET32 آسیب پذیر است
| رمزگذاری بلوک 64 بیتی vulnerable to attack SWEET32
| RF4 رفع شده توسط RFC 7465 رد شده است
| Ciphersuite از MD5 برای صداقت استفاده می کند
| تبادل کلید (dh 768) از قدرت پایین تر از کلید گواهی
| TLSv1.1:
| رمزهای عبور:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 768) - E
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 768) - C
| TLS_DHE_RSA_WITH_DES_CBC_SHA (dh 768) - E
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| کمپرسورها:
| خالی
| اولویت رمز: مشتری
| هشدارها:
| بلوک بلوک 64 بیتی 3DES به حمله SWEET32 آسیب پذیر است
| رمزگذاری بلوک 64 بیتی vulnerable to attack SWEET32
| RF4 رفع شده توسط RFC 7465 رد شده است
| Ciphersuite از MD5 برای صداقت استفاده می کند
| تبادل کلید (dh 768) از قدرت پایین تر از کلید گواهی
| TLSv1.2:
| رمزهای عبور:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 768) - E
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 768) - C
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - C
| TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - C
| کمپرسورها:
| خالی
| اولویت رمز: مشتری
| هشدارها:
| بلوک بلوک 64 بیتی 3DES به حمله SWEET32 آسیب پذیر است
| RF4 رفع شده توسط RFC 7465 رد شده است
| Ciphersuite از MD5 برای صداقت استفاده می کند
| تبادل کلید (dh 768) از قدرت پایین تر از کلید گواهی
| حداقل قدرت: E

سوالات من

  1. همانطور که در متن آمده است، کافیست که علامتگذاری شده به عنوان "E" رمز ضعیف است و به شیوه دیگری می توان رمز را به عنوان "A" به عنوان رمزنگاری قوی مشخص کرد
  2. TLS_RSA_WITH_AES_128_CBC_SHA به عنوان "A" در اینجا، اما در برخی از بحث ها، من مشاهده کرده ام آن را به عنوان WEAK ذکر شده است. آیا این به خاطر استفاده از SHA1 است؟ اگر چنین است چرا این به عنوان "A" در NMAP ارزیابی می شود؟
  3. من لیست زیر رمز در سرور من پیکربندی شده است.

    رمزهای = "SSL_RSA_WITH_RC4_128_MD5، SSL_RSA_WITH_RC4_128_SHA، SSL_DHE_RSA_WITH_DES_CBC_SHA، SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA، TLS_RSA_WITH_AES_128_CBC_SHA، TLS_DHE_RSA_WITH_AES_128_CBC_SHA، TLS_RSA_WITH_AES_256_CBC_SHA، TLS_DHE_RSA_WITH_AES_256_CBC_SHA، TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256، TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"

اما رمزهای مانند SSL_RSA_WITH_RC4_128 در خروجی از Nmap در دسترس نیست، در عوض، رمزهای مانند TLS_RSA_WITH_RC4_128 وجود دارد ، دلیل این چیست؟ آیا می توانیم از SSL و TLS به طور تعویض در Ciphers استفاده کنیم؟

  1. اگر چه من TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 را به عنوان یک رمز در سرورم اضافه کرده ام، در نتایج Nmap موجود نبود، چه چیزی ممکن است دلیل آن باشد؟

PS : من از JDK 1.7 به عنوان نسخه اصلی JDK برای سرور استفاده می کنم

TLS – چگونه حمله MiTM در گواهی خود امضا انجام شد در حالی که کلید خصوصی توسط ما تولید شده است؟

TL؛ DR: استفاده از گواهی های خود گواهی به این معنا نیست که MITM امکان پذیر است و استفاده از یک گواهی صادر شده توسط یک CA عمومی به این معنا نیست که MITM غیرممکن است. اما احتمال دارد که MITM ممکن است در صورت استفاده از گواهی های خودمختار مورد استفاده قرار گیرد زیرا مشتریانی که با گواهینامه های خود دارای گواهینامه برخورد می کنند اغلب با این روش اشتباه با آنها برخورد می کنند.


با استفاده از یک گواهی خودکارتانه MITM به طور کلی اجازه نمی دهد و استفاده از گواهی صادر شده توسط یک CA عمومی در برابر MITM به طور کلی محافظت نمی کند. به غیر از حفظ خصوصی خصوصی خصوصی، حفاظت مهم در برابر حملات MITM، نوعی گواهی در سرور نیست بلکه نحوه بررسی این گواهینامه در سرویس گیرنده، یعنی اگر سرور به درستی با استفاده از یک گواهی تأیید شود یا خیر.

روش ثابت برای تأیید هویت یک سرور با استفاده از یک گواهینامه امضا شده توسط یک CA عمومی، بررسی موضوع گواهینامه، زنجیره اعتماد، انقضا و غیره است. – چارت گواهینامه SSL 101: چگونه مرورگر در واقع اعتبار یک گواهی سرور مشخص را تأیید می کند؟ برای جزئیات بیشتر اما اگر یک مشتری این چک را انجام نمی دهد و یا این چک ها را درست انجام نمی دهد، ممکن است حمله کننده در مسیر گواهی خود را ارائه دهد و مشتری متوجه آن نخواهد شد. در گذشته چنین خطاهایی ناشی از جهل یا به علت اشکالات رخ داده است، مثلا گواهینامه ها را بررسی نکنید، اعتبار موضوع را بررسی نکنید، محدودیت های اساسی را بررسی کنید و غیره.

با گواهینامه خود امضاء شده، تأیید صحت سرور مجاز است همچنین: اگر مشتری می داند که گواهی انتظار دارد (یا کلید عمومی آن، یا یک هش از آن …) تا جلو، مشتری می تواند بررسی کند که گواهی تحویل داده شده مطابق با انتظار است. این نوع تأیید در واقع در موارد بسیاری استفاده می شود. اما در بسیاری از موارد دیگر این اشتباه انجام می شود: غیر معمول نیست که مشتریان به سادگی تمام گواهینامه های گواهینامه را به طور کامل از کار انداخته اند، در صورتی که گواهی خود گواهی خود را انتظار داشته باشند تا انتظار یک گواهی خاص خود را امضا کنند. با چنین مشتریانی که شکسته اند، MITM آسان است، زیرا مهاجم فقط می تواند از یک گواهی دلخواه استفاده کند و مشتری آن را قبول می کند.