Хайде сега пак по същество. Виждам, че обичаш да пишеш с малко думи много глупости.
Идеята на AH очевидно не си я схванал. Въпрос на интелект. При толкова обяснения и толкова литература по темата в Интернет е някак си нечовешко да не разбереш елементарни принцип. Много ме кефи обаче какви задачи си ми дал за домашно:) От тях струи простотия, която няма равна на себе си и самочувствие на селски ерген от градски тип. Но понеже обичаш конкретни неща, ето конкретно описание на простотията ти (мен би ме било срам да пиша глупости, но на теб ти е навик):
"гаси дистрибутирани DoS атаки (DDoS)... Такова нещо в OpenVPN няма" Така ли ? --tls-auth file [direction] за домашно
Бих възкликнал "Боже, ела и си го прибери". Ти очевидно не знаеш какво е TLS. Мога смело да го кажа. Как TLS спира DDoS атаки сме любопитни да чуем. Я ни осветли по въпроса. Може би ще ни кажеш и какво е изобщо DDoS и как това нещо изобщо се връзва с TLS. То бива простотия, ама а вземи се спри. Толкова кретения не се е изливала тук от как Вени Марковски спря да се прави на интернет експерт в този портал.
TLS е модификация на SSL протокола за вграждане на ниво протокол на приложение. Ти изобщо какво четеш и от къде четеш и изобщо четеш ли дори ръководството на OpenVPN и какво пише там? Наясно ли си с основни понятия за протоколи? С какво самочувствие идваш да спориш или препоръчваш решения? Известно ли ти е, че AH работи на ниво "хедър на IP пакет", а TLS работи на ниво приложение и то СЛЕД като има ръкостискане м/у клиента и сървъра в рамките на протокола на приложението?
Специално за да ти създам дискомфорт ще опиша как AH се справя с DDoS атаки и да се види ясно как ти не само не знаеш, но и се напъваш да пишеш глупости.
Така. Когато бъде извършена детекция на DDoS атака има два варианта да бъдат ограничени пораженията. При първия вариант просто се спира атакуваната услуга, докато атаката не "угасне" от самосебе си. При вторият се извършва топологично "гасене" на атаката и се пропускат само пакети от достоверни източници. Точно тук влиза в употреба AH. Може да се направи такава настройка, че да се пропускат пакети само от хостове, които имат удостоверен хедър на пакета. Така не е нужно да се прави листа за достъпа към услугата по IP адреси. Схемата осигурява свободата всеки удостоверен хост да се свърже дори в условия на атака с машината и да използва услугата. По-този начин услугата остава достъпна само за удостоверените хостове и всички други просто не могат да реализират сесия или изобщо връзка към нея.
При TLS ти удостоверяваш клиента, след като той е влязал в протокола на услугата!!! Това квадратната глава разбира ли ти го? Нали целта е при DDoS атакуващият хост изобщо да не може да стигне до порта, на който тя е достъпна. И чак след това с команда се преминава в SSL режим. Точно това е идеологията на TLS - да не се дефинира нов порт за SSL базираната услуга, а да се ползва не-SSL базирния й порт и през него да се осъществява криптиран канал след обмен на команди за целта. Тези неща ти някога осъзнавал ли си ги? Осмислял ли си ги? Какво общо има това с AH и с механизъм за защита от DDoS атака? И имаш селската наглост да ми даваш такива неща за домашни? Че ти си толкова гол и бос по тази тема, че е смешно дори да се обаждаш.
Другото домашно. Очевидно си нагъл идиот. Гледай сега момче с квадратна глава. Опцията
--crl-verify crl проверява валидност на сертификата спрямо ВЕЧЕ НАЛИЧЕН НА МАШИНАТА ТИ списък с отменени сертификати. Това НЕ Е динамична проверка за валидност. Всеки CRL е файл, който ти периодично теглиш на машината си от сайта на съответния удостоверител, сертификати на клиентите на който ще удостоверяваш. Тези неща са ти много много далеч. Сещаш ли се, че между два момента от време, ти ползваш актуален със задна дата CRL списък. Докато ти го ползваш, удостоверителят може да е отменил сертификат и съставил нов CRL лист, но понеже ти не си го изтеглил, няма да знаеш че има и още отменени сертификати. Представи си и какво става, ако удостоверителят е разбрал, че нечий частен ключ е разкрит и е отменил даден сертификат, но понеже ти не си актуализираш ежесекундно CRL файла, не знаеш, че това е така. Просто ще пуснеш в системата си комприметиран потребител. Според мен не си наясно изобщо какво е CRL и как се процедира при обновяване. Сигурен съм, че не знаеш и че всеки CRL се валидира, защото е електронно подписан от издателя си. Много много си ми далеч от тези неща. Когато ги научиш задавай домашни.
Когато имаш LDAP проверка на CRL, ти можеш с LDAP клиент през TLS (ех този TLS, само името му знаеш), да се свързваш с LDAP реплика на удостоверителя и да четеш винаги актуалния списък с отменени сертификати. Може да комбинираш LDAP с локален CRL лист, ако случайно нямаш връзка до LDAP репликата на удостоверителя.
За OCSP е смешно да обяснявам на такива като теб. Но понеже искам да ти е гадно, ще ти обясня какво е това чудо (може да стане чудо и да го разбереш). Световната интернет общност (а не клуб по ТНТМ, съставен от интравертни идиоти), е раработил протокол за проверка на валидността на X.509 сертификати в реално време. Този протокол се нарича OCSP - Online Certificate Status Protocol. Ето и пълното му описание:
http://www.faqs.org/rfcs/rfc2560.html
При добре направените (а не пръчковидни) решения за IPsec, има изграден OCSP клиент, който проверява валидността на всеки X.509 сертификат, като използва OCSP протокола (TCP базиран) за да се свърже с OCSP сървъра на съответния доставчик на удостоверителни услуги и да провери валидността на сертификата.
Що се касае до речника. IPsec и сигурните услуги не искат речник - искат знания. Е точно тези знания ти ги нямаш.
|