بعد از وقوع این ماجرا، اظهارنظرهای غیرتخصصی زیادی مطرح شد که یکی از اون‌ها نگه‌داری تتر روی شبکه‌ی BSC بود (با ذکر این دلیل که روی کانترکت تتر در این شبکه، متد فریز وجود نداره، که البته درست هم هست).

بارها این رو مطرح کردیم که BNB-Chain یک شبکه‌ی PoSA محسوب میشه. درواقع Proof of Staked Authority یک مکانیزم میانی/هیبریدی بین PoS و PoA هست. یه‌جورایی هیچ‌کدوم این دوتا نیست و همزمان جفت این‌ها هست.
حالا موضوع اینه که هر زمان اون ساید Authority اراده کنه (که از قضا به‌شدت هم متمرکز هستن در این کیس)، دیگه فرقی نمی‌کنه شما بخواید برای تتر تراکنش بزنید یا هرچیز دیگری. هیچ تراکنشی از سمت آدرس شما توی شبکه پذیرفته نخواهد شد.
اینه که آدرس شما تبدیل میشه به زباله‌دانی از توکن‌های مختلف من‌جمله تتر و همچنین خود گس شبکه.

به‌عنوان یک قاعده‌ی کلی اگر برای آرامش خاطر خودتون احترام قائل هستید از تتر و بعد از اون از BNB-Chain دوری کنید!

💚 Website
@hedgio_fa

پی‌نوشت: دلیل این‌که چرا تتر روی BNB-Chain روشی برای فریز دارایی شما هم نداره الان تقریباً واضحه دیگه. نیازی بهش نیست اصلاً!
💚 Website | @hedgio_fa

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

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

با توجه به این‌که سرتیفیکیت‌های رایگان صادر شده توسط Let's Encrypt (که بسیار هم محبوب هست) ۹۰ روزه هست، در بهترین حالت همین‌روزها باید نگران این باشید که چه‌طور برای دوره‌ی بعدی تمدید گواهی دامنه‌های خودتون رو انجام بدید!

💚 Website | @hedgio_fa

در این مقاله بررسی شده که چه‌طور از چالش DNS-01 به‌جای HTTP-01 استفاده کنیم تا ثابت کنیم مالک دامنه هستیم که بتونیم فایل‌های مربوط رو دریافت کنیم و به سرور ایران‌اکسس خودمون منتقل کنیم!
بخش یک

برای تمدید سرتیفیکیت دامنه‌های خودتون چه به‌صورت single domain یا wildcard ، پیش روی شما ابزار کاربردی certbot قرار داره که به‌صورت پیش‌فرض می‌تونه سرتیفیکت‌های ۹۰ روزه از let's encrypt بگیره و فعال کنه. پروایدرهای دیگه‌ای هم مثل ZeroSSL از این مسیر قابل دستیابی هستند.
در هر حال با استفاده از CLI مربوط به certbot شما وارد یک چلنج میشید که ثابت کنید مالک اون دامنه‌ای هستید که در حال درخواست سرتیفیکیت برای اون هستید.
پیش روی شما گزینه‌های مختلفی از جلمه موارد زیر وجود داره:

* HTTP-01 Challenge (The common challenge)
* DNS-01 Challenge
* TLS-ALPN-01 Challenge

در حالت عادی certbot مستقیم به سراغ روش HTTP میره که در اون تعدادی فایل باید به صورت پابلیک روی سرور شما در دسترس باشن تا مرجع صادرکننده از بیرون اون‌ها رو ببینه و مالکیت دامنه‌ها رو تایید کنه.
وقتی از کامندلاین استفاده کنید این فایل‌ها بدون دردسر اضافه و فرایند به صورت خودکار انجام میشه.
گاهی ممکنه دچار مشکلاتی در انجام این روش بشید (مثل شرایط فعلی ما) که مجبور بشید چالش‌های دیگری رو برای اثبات مالکیت دامنه قبول بکنید که یکی از فراگیرترین روش‌ها روش DNS-01 هست که شما در اون با قرار دادن یک سری ریکورد DNS در بخش Zone Editor محل کنترل دامنه‌ی خودتون ثابت می‌کنید مالک دامنه هستید. از اون‌جایی که در حال حاضر اکثر پرووایدرهای فعلی توانایی این رو دارن که ریکوردهای شما رو Propagate و عمومی بکنن، پس مرجع صادرکننده هم این توانایی رو داره که این ریکوردها رو از خارج از ایران ببینه! خوبی این روش اینه که روی یک ماشین دیگه هم قابل انجامه یعنی شما می‌تونید روی یک سرور/ماشین دیگه فایل‌ها رو درخواست داده و بعد به سرور مقصد بفرستید. توجه داشته باشید که تو همین مرحله می‌تونید تمام دامنه‌های مد نظر خودتون رو وارد بکنید. بهتره که حتماً URL مقادیر رو با www هم وارد کرده باشید.
برای توضیح بیشتر باید گفت که اون manual نشون میده که شما دنبال تمدید اتوماتیک نیستید و اون preferred challenges هم نشون میده که شما دنبال چه چالشی هستید که در این‌جا dns یا همون dns-01 ذکر شده است. همچنین فلگ‌های مربوط به key-type یا elliptic-curve هم الگوریتم امضای دیجیتال شما رو تعیین می‌کنن. به صورت پیش‌فرض سرتبات در این روش به سراغ ECDSA و الیپتیک کرو secp256r1 (P-256) خواهد رفت، اما شما می‌تونید از کامبینیشن‌های مختلف حاصل از RSA, ECDSA و ... استفاده کنید. البته دقت کنید که مقدار پیش‌فرض certbt در این موضوع یکی از بهینه‌ترین الگوریتم‌های ساخت امضای دیجیتال برای وبسایت‌های عادی محسوب میشه.

برای شروع درخواست این چالش کافیه کامند زیر رو در CLI خودتون وارد کنید تا چالش رو دریافت کنید:

sudo certbot certonly --manual --preferred-challenges dns \
    -d example.com \
    -d www.example.com \
    --key-type ecdsa \
    --elliptic-curve secp384r1 \
    -v

بعد از وارد کردن این درخواست برای شما ریکوردهایی که باید در DNS Zone Editor وارد کنید نمایش داده میشه که باید اون‌ها رو در تنظیمات دامنه‌ی خودتون اعمال کنید. توی این مرحله نیازه بین چند ثانیه تا چند دقیقه و حتی بیشتر صبر کنید تا مقادیر به‌طورعمومی در دسترس باشن و به اصطلاح پروپگیت بشن. می‌تونید برای مطمئن شدن از این فرایند از ابزارهایی مثل dig یا nslookup استفاده کنید. همچنین ابزار آنلاینی هم از Google Admin Toolbox در این زمینه در دسترس هست. توجه داشته باشید بعد Propagate شدن این ریکوردها و پاس کردن چالش شما می‌تونید این ریکوردها رو از Zone مربوطه حذف کنید.
بعد از پایان چالش certbot به شما ۴ فایل خواهد داد که در ادامه به اون‌ها اشاره می‌کنیم!
این فایل‌ها روی سروری که درخواست رو فرستاده در آدرس زیر در دسترس هستند:
/etc/letsencrypt/live/domain

/etc/letsencrypt/live/<domain>/
├── cert.pem
├── chain.pem
├── fullchain.pem
└── privkey.pem

💚 Website | @hedgio_fa x @soliditylang_fa

بخش دو - پایانی

شما حالا باید این فایل‌ها رو از سرور یا لوکال خودتون به سرور مقصد منتقل کنید (یا اگر فایل‌ها روی سرور مقصد ایجاد شدن، این فرایند رو نادیده بگیرید).
در اصل برای یک فعالسازی موفق شما به دو فایل fullchain.pem و privkey.pem نیاز دارید. قبل از ادامه‌ی فرایند به دایرکتوری دلخواهی که این فایل‌ها رو در سرور مقصد (ایران اکسس) منتقل کردید برید و دسترسی‌های زیر رو برای این فایل‌ها فعال کنید!
حالا نوبت می‌رسه به این‌که اگر certbot و Automatic renew برای اون سایت‌ها فعال بوده اون‌ها رو حذف کنید. به‌طور کلی شما با استفاده از دستور certbot certificates می‌تونید سرتیفیکیت‌های فعالی که توسط certbot در حال مدیریت هستند رو ببینید. یکی از مزیت‌هایی که سرتبات داره اینه که فرایند اخذ و یا تمدید گواهی در اون بسیار ساده است و حتی شما می‌تونید با قرار دادن کامندهای مربوط به renew در cronjobs این فرایند رو خودکار کنید، اما فراموش نکنید که ما الان در شرایطی هستیم که روی سرور مقصد خودمون امکان استفاده‌ی مستقیم از سرتبات و قابلیت‌هاش رو نداریم پس باید برای سایت مدنظر خودمون که گواهیش منقضی شده غیرفعالش کنیم.

chmod 600 privkey.pem
chmod 644 fullchain.pem cert.pem chain.pem
chown root:root *.pem

تا این مرحله شما تونستید فایل‌های مهم رو به سرور خودتون منتقل کنید. برای مراحل مربوط به استفاده از این فایل‌ها در وب‌سرور خودتون یا توضیحات بیشتر می‌تونید به مقاله‌ی اصلی مراجعه کنید!
https://x.com/eferbarn/status/2050988420231782543

💚 Website | @hedgio_fa x @soliditylang_fa

این روزها به‌طور فراگیر، روش‌هایی برای اتصال به اینترنت در حال گسترش هستن که در اون‌ها یک کلاینت (چه به‌صورت یک اسکریپت باشه و چه هر شکل دیگری) نقش MitM یا مرد میانی رو بازی می‌کنه. برای مثال تموم روش‌های منشعب شده از روش MHR از همین راهکار استفاده می‌کنن.

در این روش‌ها با ایجاد شدن یک سرتیفیکیت Self-Signed کلاینت می‌تونه ترافیکی عبوری از مرورگر (و سایر بخش‌های ماشین) شما که از این پراکسی گذر می‌کنه رو رمزگشایی کنه، و بعد دوباره اون‌ها رو با متد خودش ارسال و دریافت کنه.
بگذریم که خود این کلاینت‌ها و امنیتشون یک نقطه‌ی شکست محسوب میشن، اما نکته‌ی اساسی، نگهداری فایل‌های سرتیفیکیت (یعنی cert و key) هست که اصلا به اون توجه نمیشه. خصوصاً جابه‌جایی اون‌ها بین دیوایس‌های مختلف و نگهداریشون به‌صورت خام داخل دایرکتوری‌ها، می‌تونه شما رو به‌طور بالقوه به یک طعمه تبدیل کنه.
توجه داشته باشید که هر شخص ثالثی می‌تونه با داشتن این فایل‌ها، ترافیک شما رو رمزگشایی و شنود کنه. این شامل رمزها و کلیدهایی که تبادل می‌کنید هم هست.

نباید کار به این نقطه می‌رسید که سراغ روش‌های با ریسک ساختاری بسیار بالا بریم، اما حالا که رسیدیم، چاره‌ای نیست که حواسمون خیلی جمع باشه.

💚 Website | @hedgio_fa

اگر ناچار به استفاده از این روش‌ها هستید، با جدیت بیشتری موضوع امنیت رو مدنظر داشته باشید. فایل‌های سرتیفیکیت رو به‌صورت دوره‌ای Rotate کنید و تا حد امکان امکان دستیابی هر فرد دیگری به این فایل‌ها رو ناممکن کنید.
💚 Website | @hedgio_fa

در ادامه‌ی پست بالا باید دنبال راهکاری باشیم تا بتونیم خطرات بالقوه رو کاهش بدیم.
پیش از ورود به بحث باید گفت که ما دست کسانی که به دسترسی افراد به اینترنت آزاد کمک می‌کنند رو می‌بوسیم و صدها لعنت می‌فرستیم به باعثان این شرایط.

همون‌طور که می‌بینید وقتی Self-Hosted Authority ما یک سرتیفیکیت ایجاد کرده، سیستم‌عامل در تلاشه که اون رو در کل سیستم اعمال کنه و به‌عبارت دیگه اون رو به Trusted Root اضافه کنه.
این باعث میشه که خطاهای انسانی یا دسترسی‌های ناخواسته وارد فرایند بشه. پس ما باید دنبال یک راهکار خوب برای استفاده‌ی مطمئن باشیم.

مشکل از کجا ناشی میشه؟
🟥 این فرایندها در ابتدا در کنترل شما هستند و خب تا این‌جا مشکلی نیست. اما پس از مدتی هیچ‌گونه الزامی وجود نداره که اپ‌ها یا جاسوس‌افزارهای دیگه اعم از اپلیکیشن‌ها یا چیزهایی که روی دسکتاپ یا موبایلتون دارید، دنبال فایل‌های مرتبط با رمزگشایی ترافیک شما نگردن. خصوصا در پلتفرم‌های همه‌گیری مثل اندروید و ویندوز خیلی از دسترسی‌ها به‌صورت ناخواسته از قبل داده شده و ممکنه در روزهای خاص از اون دسترسی‌ها استفاده بشه.
🟥 اگر روزی دسترسی آزاد واقعی به اینترنت برای شما فراهم بشه، احتمالا با فرایند ابطال اون سرتیفیکیت‌های قدیمی آشنایی ندارید یا حتی ممکنه یادتون بره که این سرتیفیکیت‌ها رو باطل کنید و از Trusted Root اون‌ها رو خارج کنید.

بهترین راه اینه که بتونید یک Sandbox یا به‌عبارتی یک محیط قابل کنترل و امن ایجاد کنید تا هر لحظه روی اون و دیتایی که واردش می‌کنید اشراف کامل داشته باشید و در زمان نیاز هم حذفش کنید.
در پست بعدی به بررسی یک راهکار ایمن در این زمینه می‌پردازیم.

💚 Website | @hedgio_fa

جلسه بحث آزاد ❗️

⬅️ موضوع گفتگو :
- قراره درمورد Polymarket و ریسک هاش حرف بزنیم.
- قراره درمورد خطرات احتمالی سروها یا Vpn هایی که برای وصل شدن استفاده میکنیم حرف بزنیم.
- مثل همیشه بحث آزاد هم هست شما میتونید بیاد درمورد هر موضوعی دوست داشتید باهم حرف بزنیم.

⬅️ با همکاری :
مهدی کانال Hedgio
محمد کانال CryptoCraze

⬅️زمان جلسه دوشنبه 4 خرداد ساعت 9 شب به تایم ایران
⬅️ مکان جلسه کانال تلگرام Defi Avenue

🎺 جلسه ضبط نمیشه

✉️ Telegram
❌ Twitter

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

https://www.youtube.com/watch?v=BPkLUdMcPLY

💚 Website | @hedgio_fa

برای ایردراپ شبکه‌ی بیس دوستان میگن که خیلی از شبیه‌سازهای ایردراپ، کانترکت‌های دپلوی شده توسط جاهایی مثل owlto رو حساب نمی‌کنن و اون‌ها رو نادیده می‌گیرن.
اگرچه راه برای پیدا کردن کانترکت‌های کوچک و ساده زیاده اما اگر خواستین می‌تونید از این ریپازیتوری قدیمی استفاده کنید:
https://github.com/eferbarn/Simple-Solidity-Contracts

برای ساده‌ترین روش دپلوی کردن هم می‌تونید سراغ Remix برید.
کافیه والت‌تون رو وصل کنید و چین آی‌دی رو هم روی 8453 یا همون chainID مین‌نت بیس تنظیم کنید و بعد مراحل رو پیگیری کنید. (راهنما)


💚 Website | @hedgio_fa

تیم Circle که صادرکننده‌ی استیبل‌کوین USDC محسوب میشه و به تنبل‌بودنش در فریز کردن وجوه مشکوک در مقایسه با بنیاد تتر معروف بود، در یک اقدام عجیب کانترکت cUSDC از پروژه‌ی Zama (یک پروژه در سکتور پرایوسی روی اتریوم) رو فریز کرد که در اون حدود 12.6 میلیون دلار USDC وجود داشت.
Circle blacklisted the Zama cUSDC contract

طبق اعلام و بررسی ZachXBT، این اقدام به دلیل گزارش کاربران درمورد یک راگ‌پول از طرف تیم Overnight Finance و واریز وجوه مربوط به این اتفاق از طرف یکی از آدرس‌ها وابسته به همین ماجرا به پروژه‌ی زاما هست.

چیزی که این‌جا مورد بحث هست اینه که چرا کانترکتی که می‌تونه آمیخته با وجوه کاربران عادی Zama بشه بلک‌لیست و فریز شده؟
مورد مهم‌تر برای ما اینه که به‌نظر می‌رسه مجموعه‌ی سرکل بعد از این می‌تونه رویکرد بنیاد تتر رو در پیش بگیره و این موضوع هر دو دارایی $USDT و $USDC رو به کلاس دارایی‌های پرریسک منتقل کنه.

💚 Website | @hedgio_fa

یکی از دوستان درمورد استفاده از نرم‌افزارهای مدیریت پسورد مردد بودن. خیلی اجمالی اگر بخوایم جواب بدیم، خوبه، کار رو راه میندازن، اما حواستون باشه خودشون می‌تونن عامل دردسر بشن.
کما این‌که شواهدی وجود داره که درین شدن والت‌های اتریومی باسابقه که سال‌ها ایمن مونده بودن، مربوط به یک بریچ از نرم‌افزار مدیریت پسورد LastPass هست و نگهداری فریزها توی این نرم‌افزارها باعث این دسترسی کامل به آدرس‌ها شده.
LastPass Breach Fallout + Ethereum Wallets Suddenly Drained

💚 Website | @hedgio_fa

آیا در این لحظه باید نگران کامپیوترها و پردازش کوانتومی باشیم؟
(این صرفاً یک اظهار نظر بسیار عامیانه از بنده است در باب این پست از کانال دیفای اونیو)

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

پی‌نوشت: خیلی اتفاقی یاد سری تلویزیونی Prime Target افتادم. نام این اثر اشاره‌ی واضحی به معادل انگلیسی «اعداد اول» داره. احتمالاً می‌دونید که شالوده و اساس بسیاری از سیستم‌های رمزنگاری امروزی غیرقابل‌پیش‌بینی بودن توزیع اون‌ها (به‌طور درست‌تر سختی شکسته‌شدن یک عدد بسیار بزرگ حاصل از ضرب دو عدد اول به عوامل اول خودش) است. فکر می‌کنم از دیدن این سری خوشتون خواهد اومد.

پی‌نوشت دوم: حدس اینه که این توازن همیشگی (بین پیشرفت در پردازش و سیستم‌های رمزنگاری) به‌هم نخواهد خورد و ما به‌سمت روش‌های Quantum-Resistant پیش خواهیم رفت.

💚 Website | @hedgio_fa

در ادامه‌ی این پست، حتماً کنجکاو خواهید شد اگر بدونید که بنیاد تتر تا امروز ۱۲۵۳ بار آدرس‌هایی از شبکه‌های اتریوم و ترون که شاید به اشتباه وارد بلک‌لیست خودش شده بودند رو از این لیست خارج کرده.

این آدرس‌ها و تراکنش‌های مربوط به Remove رو در این لینک می‌تونید ببیند (برگرفته از این دیتاست):
https://gist.github.com/eferbarn/a7e0de96bcf83ec61dafa123ba40be7e

البته برای دیدن تراکنش‌های مربوطه باید بدونید که چون مالتی‌سیگ (اونر) کانترکت تتر تراکنش‌ها رو ارسال می‌کنه (این آدرس دارای ۶ ساینر هست که از این‌جا می‌تونید اون‌ها رو ببینید) و بعد از شرایط خاصی تراکنش کانفرم میشه، باید ابتدا از دیتای تراکنش آی‌دی تراکنش اصلی رو پیدا کنید و بعد از طریق این متد (transactions) کال‌دیتای تراکنش Remove رو استخراج کنید.

برای راحتی کار اطلاعات کافی در لینک gist قرار داده شده تا شما درگیر این مراحل نشید.

💚 Website | @hedgio_fa