مقایسه HTTP و HTTPS؛ نقش TLS، گواهی و اثر عملی بر امنیت

مقدمه

گواهی منقضی یا chain ناقص می‌تواند API و automation را هم‌زمان قطع کند. HTTPS علاوه بر رمزنگاری، تأیید هویت مقصد و سلامت chain را به lifecycle گواهی وابسته می‌کند.

تفاوت HTTP و HTTPS در عمل

HTTPS امنیت انتقال را فراهم می‌کند؛ آسیب‌پذیری برنامه، مجوز اشتباه یا سرقت حساب را برطرف نمی‌کند. گواهی معتبر نیز کیفیت یا قابل اعتماد بودن کسب‌وکار را اثبات نمی‌کند. اصطلاح SSL در نام قدیمی مقاله حفظ شده، اما پیاده‌سازی جاری باید TLS باشد.

مثال عملی

API سازمان پشت TLS proxy است؛ browser و jobهای Linux از trust store متفاوت استفاده می‌کنند. rollout با کلاینت canary و سپس HSTS کوتاه آغاز می‌شود.

پیش‌نیازها

Ubuntu Server 24.04 LTS، Bash 5، systemd؛ package patch را پیش از تغییر با dpkg-query ثبت کنید. OpenSSL 3.x، curl و Nginx از repository؛ حداقل TLS 1.2 و پشتیبانی TLS 1.3 مطابق client policy.

سخت‌افزار و ظرفیت: برای مثال یک VM با ۲ vCPU، ۲ GiB RAM و ۲۰ GiB دیسک؛ این ظرفیت پیشنهادی آزمایشگاه است و sizing سرویس به بار واقعی وابسته است.

نرم‌افزار و دسترسی: DNS app.example.com، CA داخلی یا عمومی معتبر، certificate شامل SAN، fullchain و key با permission محدود. sudo فقط برای config proxy.

Architecture / Design

DNS/SNI → TLS handshake → chain/hostname verification → HTTP request → backend. TLS termination باید مرز اعتماد proxy تا backend را نیز مشخص کند.

Installation / Configuration

app.example.com placeholder مقصد واقعی است. ابتدا certificate و chain بدون bypass تست شوند.

HOST='app.example.com'
openssl s_client -connect "$HOST:443" -servername "$HOST" -verify_hostname "$HOST" -verify_return_error </dev/null
curl --fail --show-error --head "https://$HOST/"

انتظار Verify return code: 0 (ok)، hostname صحیح و status مورد انتظار endpoint. برای CA داخلی به‌جای -k، CA مصوب را به trust store یا --cacert فایل معتبر بدهید.

config کامل TLS و redirect در مقاله Nginx این مجموعه آمده است. پس از استقرار آن، فقط در server block HTTPS این directive کامل افزوده شود؛ این snippet مستقل config کامل Nginx نیست.

add_header Strict-Transport-Security "max-age=300" always;

sudo nginx -t
sudo systemctl reload nginx
curl --fail --head https://app.example.com

header باید فقط روی HTTPS و max-age کوتاه دیده شود. پس از اطمینان از تمام hostnameها و renewal، مدت افزایش یابد. includeSubDomains و preload فقط پس از inventory کامل و برنامه recovery انتخاب شوند.

Security Hardening

SSL نام رایج قدیمی است؛ SSLv2/v3 نباید baseline باشد. private key root-only و chain معتبر. از 0-RTT برای درخواست state-changing بدون تحلیل replay استفاده نشود. redirect با hostname ثابت مانع اعتماد بی‌جا به Host ورودی می‌شود.

Monitoring

پایش certificate از مسیر واقعی کاربر شامل SAN، chain و expiry باشد؛ فایل روی disk شاید با certificate سرو شده متفاوت باشد. probe TLS و آزمون API هر دو؛ هشدار expiry در ۳۰/۱۴/۷ روز نمونه است.

Troubleshooting

Expired: زمان واقعی client/server و notAfter. hostname mismatch: DNS/SAN/SNI. issuer unknown: intermediate و CA trust. curl موفق ولی browser خطا: mixed content، cache/HSTS یا trust store متفاوت. Error در upstream HTTP الزاماً TLS client نیست. openssl بدون -verify_return_error ممکن است handshake را با هشدار ادامه دهد؛ نتیجه را درست تفسیر کنید.

Backup / Recovery

key/cert و config به vault امن backup شوند؛ chain قدیمی معتبر برای rollback deploy قابل نگهداری است. بعد renewal reload و remote probe لازم است. HSTS در client cache می‌شود؛ max-age=0 فقط روی HTTPS معتبر policy را حذف می‌کند و recovery فوری همه کلاینت‌ها را تضمین نمی‌کند. preload حذف فرآیند و زمان مستقل دارد.

Best Practices

Automation renewal، canary trust test و مالک گواهی تعریف شود. -k برای acceptance test استفاده نشود. HTTPS به‌تنهایی امنیت application یا endpoint آلوده را حل نمی‌کند.

نسخه‌های قدیمی و Compatibility

TLS 1.3 با TLS 1.2 رفتار cipher و handshake متفاوت دارد؛ policy clientهای قدیمی با منبع رسمی تطبیق شود. HSTS نیاز HTTPS فعال معتبر دارد؛ redirect جای HSTS نیست.

پرسش‌های متداول

آیا redirect جای HSTS است؟

خیر؛ HSTS policy مرورگر را پس از دریافت از HTTPS معتبر تعیین می‌کند.

چرا گواهی معتبر روی disk کافی نیست؟

سرویس ممکن است certificate قبلی را serve کند؛ probe از مسیر واقعی client لازم است.