شفافیت گواهی و افشای نام جایگزین

شفافیت گواهی و افشای نام جایگزین

شاید شما درباره شفافیت گواهی و گزارش آن چیزی شنیده باشید. با استناد به ویکی پدیا: "شفافیت گواهی (CT) یک استاندارد امنیتی اینترنتی و چارچوب منبع باز برای نظارت و ممیزی گواهینامه های دیجیتال است." اساساً ، اطلاعاتی را درباره هرگونه گواهی عمومی که صادر می شود به شما می دهد. علاوه بر مزایای آن ، من به یک مشکل احتمالی فکر کردم زیرا هنگام استفاده از گواهینامه های TLS ، به عنوان مثال از Let’s Encrypt ، تمام FQDN ها را به مردم نشت می کند. گواهی نامه با دو نام DNS (نام جایگزین موضوع SAN) كه باید از آنها "خصوصی" نگهداری شود .

از این رو من خود آزمایشی کردم که در آن دو گواهی با نام تصادفی ایجاد کردم و سرورهای معتبر DNS و همچنین آدرس IPv6 این نام ها را کنترل کردم تا بررسی کنم که در حال برطرف کردن / اتصال به نام میزبان نامشخص است . اینجا برویم:

TL ؛ DR: طی یک دوره آزمایشی 8 ماهه (1) FQDN کاملاً پنهان من 700 بار با پرس و جوهای DNS حل شد ، در حالیکه 73 اتصال IPv6 HTTPS وارد شد (2) FQDN دوم من (SAN در وبلاگ من) حدود 500 بار مورد سال قرار گرفت ، در حالی که 273 اتصال IPv6 وارد شد ، به پورت 80 و 443 تقسیم شده است. یعنی: هر دو نام میزبان کاملاً بلااستفاده "درز کرده است" و فقط با استفاده از گواهینامه های X.509 توسط مردم اسکن می شود!

The Setup

من از نامهای میزبان و آدرس IPv6 به طور تصادفی ایجاد شده استفاده کردم:

  1. گواهی اجازه دهید با یک نام DNS رمزگذاری کنیم که من هرگز در هر کجا استفاده می شود من حتی برای آن یا موارد مشابه آن گوگل نکردم. نامش هست
    7qftpqiw5m.ib.weberdns.de با داشتن یک رکورد واحد AAAA با اشاره به
    2001: 470: 765b: 0: 747d: 36b6: 0d74: f26a . صادر شده در 2019-10-30 14:49 UTC ، CT در اینجا وارد شوید: https://crt.sh/؟id=2053680948.cepts19659012] گواهی LE دیگری با نام DNS
    xd524olksc.ib.weberdns.de (با AAAA به
    2001: 470: 765b: 0: d302: 1962: 0df9: 91eb ) همراه با weberblog.net و blog.webernetz.net (نام میزبان قدیمی من برای وبلاگ). در واقع ، من از این گواهی به مدت 2،5 ماه در وبلاگ خود استفاده کردم و به بسیاری از اشخاص امکان دیدن نام میزبان را داد. صادر شده در 2019-10-30 15:09 UTC ، CT اینجا وارد شوید: https://crt.sh/؟id=2053730087. در وبلاگ من تا تاریخ 15-15/01/20 13:55 بعد از ظهر فعال بود.

همانطور که هر دو گواهینامه توسط Let's Encrypt صادر شد ، اعتبار آنها پس از 90 روز به پایان رسید.

از آنجا که من سرورهای معتبر DNS را برای * کنترل می کنم. ib.weberdns.de (Infoblox VM ها با ورود به سیستم پرس و جو فعال هستند) و همچنین فضای IPv6 2001: 470: 765b :: / 64 (اتصال کارگزار تونل HE از طریق فایروال Palo Alto Networks من) توانستم همه را بگیرم جستجوی تک DNS و تلاش برای اتصال IP . ؛) با این حال ، تمام اتصالات به طور کامل مسدود شده بودند. هیچ سرویسی به آن آدرس های IPv6 گوش نمی داد.

بسیاری از درخواست های DNS و اتصالات IP

پس از صدور دو گواهینامه ، گواهی دوم (با SAN) را در وبلاگ خود قرار دادم. برای هر دو نام میزبان ، بلافاصله چند درخواست DNS در سرورهای DNS مشاهده کردم. و همچنین اتصالات ورودی به آدرس های IPv6:

در اینجا تصویری از Palo Alto نشان داده شده است که دو قانون مسدود کردن و بازدیدهای آنها را نشان می دهد:

توجه داشته باشید که من * فقط * اتصالات ورودی IPv6 را تحلیل کردم. بله ، این بهینه نیست ، اما 100٪ احتمال دارد که همه این تلاش ها از ایستگاه های واضحی صورت گرفته باشد که نام میزبان من را س ratherال می کند نه اسکن های پورت عادی. (بعید است اسکن پورت به آدرسهای تصادفی IPv6 زیرا فضای شناسه میزبان در a / 64 2 ^ 64 است. به پست من در مورد سر و صدای اینترنت مراجعه کنید.)

تحلیل من

من مرور کردم پرونده های گزارش از سرورهای معتبر DNS و همچنین از فایروال. همانطور که انتظار می رفت ، صدها تلاش برای اتصال به نام میزبان وجود دارد: منابع) 642
(307) 357
(228) جستجوی DNS برای AAAA
(منابع منحصر به فرد) 37
(32) 117
(99) درخواست های DNS برای CAA
(منابع منحصر به فرد) 3
(3) 24
(14) تمام RR های مورد پرسش 642 A
37 AAAA
22 MX
6 DS
5 NS
3 TXT
3 SOA
3 CAA
2 CNAME 357 A
117 AAAA
29 MX
24 CAA
8 TXT
8 NS
7 SOA
4 DS
3 CNAME
2 DNSKEY اتصالات IPv6
( منابع منحصر به فرد)
[unique /32] 73
(15)
[2] 273
(46)
[14] بنادر مقصد 73x 443 154 x 80
122x 443 Assourcing ASes 14 DigitalOcean، LLC
1 Google LLC 14 DigitalOcean، LLC
8 Quintex Alliance Consulting
6 Emerald Onion
4 Google LLC
4 F3 Netze eV
2 Zwiebelfreunde eV
2 Nexeon Technologies، Inc.
1 OVH Ltd
1 Keyweb AG
1 Joey Julian Koenig
1 Hydra Communications Ltd
1 Hurricane Electric LLC
1 الك لارسن

QED

در حالی كه اولین FQDN پرس و جوهای DNS بیشتری داشت ، مورد دوم تلاش بیشتری برای اتصال داشت.

من به هر كدام نگاه نكرده ام آدرس منبع IPv6 ، اما به نظر می رسد موارد جالب وجود دارد. البته ، این Google است. و اغلب DigitalOcean که احتمالاً فقط میزبان مواردی است؟ (آیا کسی می داند Let’s Encrypt خود در کجا میزبانی شود؟) بعلاوه ، حداقل یک گره خروجی Tor با توجه به جستجوی whois وجود دارد. و Technische Universitaet Muenchen سوابق CAA نام میزبان را فقط چند ثانیه پس از ورود به سیستم CT بررسی كرد. احتمالاً تحقیقی در اینجا ادامه دارد؟ همان Cloudflare ، که فقط سابقه CAA را زیر س quال برد.

تحلیل بیشتر

مثل همیشه ، با این داده ها می توانید کارهای بسیار بیشتری انجام دهید. در ابتدا ، رسم نمودارهای زیبا تر برای درک آسانتر داده ها نسبت به مقادیر خام. ؛) اما همچنین برخی از تجزیه و تحلیل های دیگر مانند:

  • جدول زمانی پرس و جو <- این احتمالاً در چند ساعت اول نمایش داده شد که در مقایسه با بقیه دوره آزمون
  • همبستگی مشتریان DNS (فرستنده DNS query) و آدرسهای IPv6 که ارتباطات واقعی را با سرورها تأمین می کنند <- احتمالاً هیچ ارتباط زیادی در اینجا وجود ندارد زیرا اولین نمایشگرهای DNS بازگشتی را نشان می دهد در حالی که دومین خزنده های Google
  • نگاه عمیق تری به آدرس IPv6 منبع دارند <- جزئیات بیشتر در مورد خزنده های موتور جستجو ، پروژه های دانشگاهی ، گره های خروج TOR و کلیک های تصادفی شخصی درصورتی که کسی نام میزبان عجیب و غریب را در گواهی وبلاگ من مشاهده کرده است. برای موارد استفاده خصوصی هر FQDN بلافاصله در سیاهههای مربوط به CT تبلیغ می شود و اسکن می شود! از آنجا که نرخ پرس و جو برای سوابق A بسیار بیشتر بود ، به احتمال زیاد دو صد تلاش اتصال برای هر نام میزبانی که در سیاهههای مربوط به CT عمومی ظاهر شده است یا فقط یک نام جایگزین موضوع در یک گواهینامه عمومی است

    .

    ضمیمه

    اگر می خواهید به سیاهههای مربوط به خام نگاهی بیندازید ، در اینجا می خواهیم:

    من از دستورات پوسته زیر برای تجزیه و تحلیل خود استفاده کردم (مراجعه به تجزیه Logfile ):

    نعمت خدا!

    عکس توسط AbsolutVision در Unsplash.