» NAT и публикация сервисов с учётом virtual hosts

Цитата:

например, VRF?

с точки зрения цисковеда VRF это создание на одном физическом фаерволе/роутере несколько виртуальных, по умолчанию, ни как не связанных друг с другом. После чего с помощью того же vrrp из них можно сделать отказоустойчивый шлюз.

LevT
Ух, ну там и простыня из правил... Извентиляюсь, но мне так тяжко читать, дайте пожалуйста вывод iptables -nL

[more]
Код:
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
idrop all -- 0.0.0.0/0 0.0.0.0/0 state INVALID
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
inospoof all -- 0.0.0.0/0 0.0.0.0/0
iexternalmodules all -- 0.0.0.0/0 0.0.0.0/0
iexternal all -- 0.0.0.0/0 0.0.0.0/0
inoexternal all -- 0.0.0.0/0 0.0.0.0/0
imodules all -- 0.0.0.0/0 0.0.0.0/0
iintservs all -- 0.0.0.0/0 0.0.0.0/0
iglobal all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT icmp !f 0.0.0.0/0 0.0.0.0/0 icmp type 8 state NEW
ACCEPT icmp !f 0.0.0.0/0 0.0.0.0/0 icmp type 0 state NEW
ACCEPT icmp !f 0.0.0.0/0 0.0.0.0/0 icmp type 3 state NEW
ACCEPT icmp !f 0.0.0.0/0 0.0.0.0/0 icmp type 4 state NEW
ACCEPT icmp !f 0.0.0.0/0 0.0.0.0/0 icmp type 11 state NEW
ACCEPT icmp !f 0.0.0.0/0 0.0.0.0/0 icmp type 12 state NEW
idrop all -- 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy DROP)
target prot opt source destination
fdrop all -- 0.0.0.0/0 0.0.0.0/0 state INVALID
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
fnospoof all -- 0.0.0.0/0 0.0.0.0/0
fredirects all -- 0.0.0.0/0 0.0.0.0/0
fmodules all -- 0.0.0.0/0 0.0.0.0/0
ffwdrules all -- 0.0.0.0/0 0.0.0.0/0
fnoexternal all -- 0.0.0.0/0 0.0.0.0/0
fdns all -- 0.0.0.0/0 0.0.0.0/0
fobjects all -- 0.0.0.0/0 0.0.0.0/0
fglobal all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT icmp !f 0.0.0.0/0 0.0.0.0/0 icmp type 8 state NEW
ACCEPT icmp !f 0.0.0.0/0 0.0.0.0/0 icmp type 0 state NEW
ACCEPT icmp !f 0.0.0.0/0 0.0.0.0/0 icmp type 3 state NEW
ACCEPT icmp !f 0.0.0.0/0 0.0.0.0/0 icmp type 4 state NEW
ACCEPT icmp !f 0.0.0.0/0 0.0.0.0/0 icmp type 11 state NEW
ACCEPT icmp !f 0.0.0.0/0 0.0.0.0/0 icmp type 12 state NEW
fdrop all -- 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy DROP)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
odrop all -- 0.0.0.0/0 0.0.0.0/0 state INVALID
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
ointernal all -- 0.0.0.0/0 0.0.0.0/0
omodules all -- 0.0.0.0/0 0.0.0.0/0
oglobal all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT icmp !f 0.0.0.0/0 0.0.0.0/0 icmp type 8 state NEW
ACCEPT icmp !f 0.0.0.0/0 0.0.0.0/0 icmp type 0 state NEW
ACCEPT icmp !f 0.0.0.0/0 0.0.0.0/0 icmp type 3 state NEW
ACCEPT icmp !f 0.0.0.0/0 0.0.0.0/0 icmp type 4 state NEW
ACCEPT icmp !f 0.0.0.0/0 0.0.0.0/0 icmp type 11 state NEW
ACCEPT icmp !f 0.0.0.0/0 0.0.0.0/0 icmp type 12 state NEW
odrop all -- 0.0.0.0/0 0.0.0.0/0

Chain drop (15 references)
target prot opt source destination
DROP all -- 0.0.0.0/0 0.0.0.0/0

Chain fdns (1 references)
target prot opt source destination
ACCEPT udp -- 0.0.0.0/0 10.1.1.22 state NEW udp dpt:53
ACCEPT tcp -- 0.0.0.0/0 10.1.1.22 state NEW tcp dpt:53
ACCEPT udp -- 0.0.0.0/0 8.8.8.8 state NEW udp dpt:53
ACCEPT tcp -- 0.0.0.0/0 8.8.8.8 state NEW tcp dpt:53
ACCEPT udp -- 0.0.0.0/0 8.8.4.4 state NEW udp dpt:53
ACCEPT tcp -- 0.0.0.0/0 8.8.4.4 state NEW tcp dpt:53

Chain fdrop (8 references)
target prot opt source destination
drop all -- 0.0.0.0/0 0.0.0.0/0

Chain ffwdrules (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT tcp -- 84.1.1.1 10.1.2.1 tcp dpt:8291 #на микротик с VRRP-интерфейсом в кач-ве дефолтного шлюза локалки
ACCEPT tcp -- 84.1.1.1 0.0.0.0/0 tcp dpt:3389 #это я добавил себе дырки админские

Chain fglobal (1 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

Chain fmodules (1 references)
target prot opt source destination

Chain fnoexternal (1 references)
target prot opt source destination
fdrop all -- 0.0.0.0/0 0.0.0.0/0 state NEW
fdrop all -- 0.0.0.0/0 0.0.0.0/0 state NEW

Chain fnospoof (1 references)
target prot opt source destination
fnospoofmodules all -- 0.0.0.0/0 0.0.0.0/0
fdrop all -- 10.111.113.0/28 0.0.0.0/0
fdrop all -- 79.120.51.0/29 0.0.0.0/0
fdrop all -- 195.239.106.148/30 0.0.0.0/0

Chain fnospoofmodules (1 references)
target prot opt source destination

Chain fobjects (1 references)
target prot opt source destination

Chain fredirects (1 references)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 10.1.1.6 state NEW tcp dpt:3389 #только RDP, микротик еще не добавлен в Port Fowarding

Chain ftoexternalonly (0 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
fdrop all -- 0.0.0.0/0 0.0.0.0/0

Chain idrop (7 references)
target prot opt source destination
drop all -- 0.0.0.0/0 0.0.0.0/0

Chain iexternal (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0
drop tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:587 state NEW
drop tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:4190 state NEW
drop tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:143 state NEW
drop tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:993 state NEW
drop tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:110 state NEW
drop tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:995 state NEW
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 state NEW
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:465 state NEW
drop udp -- 0.0.0.0/0 0.0.0.0/0 udp dpts:10000:20000 state NEW
drop udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:5036 state NEW
drop udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:4569 state NEW
drop udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 state NEW
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:1723 state NEW
ACCEPT 47 -- 0.0.0.0/0 0.0.0.0/0 state NEW

Chain iexternalmodules (1 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0

Chain iglobal (1 references)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:587 state NEW
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:4190 state NEW
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:143 state NEW
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:993 state NEW
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:110 state NEW
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:995 state NEW
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 state NEW
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:465 state NEW
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpts:10000:20000 state NEW
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:5036 state NEW
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:4569 state NEW
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 state NEW
drop tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:389 state NEW
drop tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:6677 state NEW
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53 state NEW
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 state NEW
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:67 state NEW
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:69 state NEW
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 state NEW

Chain iintservs (1 references)
target prot opt source destination

Chain imodules (1 references)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:3128

Chain inoexternal (1 references)
target prot opt source destination
idrop all -- 0.0.0.0/0 0.0.0.0/0 state NEW
idrop all -- 0.0.0.0/0 0.0.0.0/0 state NEW

Chain inointernal (0 references)
target prot opt source destination

Chain inospoof (1 references)
target prot opt source destination
inospoofmodules all -- 0.0.0.0/0 0.0.0.0/0
idrop all -- 10.1.1.0/28 0.0.0.0/0
idrop all -- 79.1.1.0/29 0.0.0.0/0
idrop all -- 195.1.1.0/30 0.0.0.0/0

Chain inospoofmodules (1 references)
target prot opt source destination

Chain log (0 references)
target prot opt source destination
RETURN all -- 0.0.0.0/0 0.0.0.0/0

Chain odrop (2 references)
target prot opt source destination
drop all -- 0.0.0.0/0 0.0.0.0/0

Chain oglobal (1 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW

Chain ointernal (1 references)
target prot opt source destination
ACCEPT udp -- 0.0.0.0/0 10.1.1.22 state NEW udp dpt:53
ACCEPT tcp -- 0.0.0.0/0 10.1.1.22 state NEW tcp dpt:53
ACCEPT udp -- 0.0.0.0/0 8.8.8.8 state NEW udp dpt:53
ACCEPT tcp -- 0.0.0.0/0 8.8.8.8 state NEW tcp dpt:53
ACCEPT udp -- 0.0.0.0/0 8.8.4.4 state NEW udp dpt:53
ACCEPT tcp -- 0.0.0.0/0 8.8.4.4 state NEW tcp dpt:53
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:53
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:53

Chain omodules (1 references)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:25
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443

LevT
Меня глючит или вы где-то писали что у вас внутрь сети непосредственно с роутера не проходили trace'ы?

Что касается корявости правили или нет, полностью сказать не могу (не видел iptables -vnL, думаю можно не скидывать, скорее всего совсем лажу они не допустили). Вообще я лично ни когда не разбиваю трафик еще по цепочкам int_input, ext_input и т.п., меня даже это коробит при чтении правил в SuSE. Привыкнуть я к этому могу, но практической пользы не вижу. Я правила всё равно всегда читаю в конфиге (bash скрипт или файл пригодный для restore), а в вывод iptables смотрю только если за динамическими записями или счётчиками пакетов.
То, что везде к правилам дописано cstate NEW это хорошо, я обычно не пишу, хотя правильнее писать. А вот при указании правил для одиночного ip, предпочитаю явно указывать префикс /32.
Ну и можно добавлять правила для защиты от атак (проверка количества соединений в секунду) и сканирований (проверка флагов и размеров пакета, создание ловушек). Так же некоторые отлупы можно и логировать (-j LOG).

Трейсы не проходили на прошлой инкарнации зентияла, той, которая в результате моих ковыряний в вебморде периобрела левую таблицу маршрутов 103. Я её сохранил в снапшоте на случай желания и возможности покопаться - а зентиял переустановил начисто. )

Спасибо за отзыв.

Alukardd

Как с помощью nginx проксировать запросы http://portаl.mydоmain.lаn на https://portal.mydomain.lan ?

FYI:
К вебсервисам типа portal доступ изнутри локалки бывает:
1) стандартным способом с дописыванием суффикса mydomain.lan

2) проприетарным мелкомягким способом с помощью CNAME записи в зоне GlobalNames (эта фигня предназначена для того, чтобы уйти от WINS в масштабах AD (то есть например при слиянии организаций).

LevT
Что-то я не пойму... Если http и https находятся на разных машинах (разные ip), то CNAME ваш вариант, ну или redirect (http 301).
Как бы если клиенты будут обращаться к http серверу то сессия защищена не будет от того, что он будет проксировать это к https backend'у. Будет защищен канал между nginx и реальным сервером, оно вам надо?)

Мб я что-то не так понял?..

про HTTP редирект спасибо, не думал что это можно применить

Добавлено:

Я хочу, чтобы не надо было учить юзеров, чем отличается https от http
Опыт показывает, что это трудная задачка, ресурсоёмкая. Я свое время на что-нибудь более интересное потрачу. )

Какие вообще существуют варианты редиректа http:// на https:// ?
Предлагаю составить в этой теме шпаргалку для всех случаев.

LevT
В смысле какие варианты? Ты так и не ответил, нужно ли что бы сессия с пользователем шифровалась или просто любым способом достучаться до https сайта, который по каким-либо причинам не предоставляет доступа по http?

Добавлено:
Вообще применяются 2 http ошибки:
301 Moved Permanently
302 Moved temporarily
Можно и страничку набросать на php с перекидыванием или даже JS скрипт...
Собственно вот сразу все примеры...

Цитата:

просто любым способом достучаться до https сайта, который по каким-либо причинам не предоставляет доступа по http?

Второе.

Требования секурности в основном нет. Сертификатов своих пока нет, их только планируется внедрять - но не столько для секурности, сколько для менее геморройного использования существующих https сервисов (не всегда можно их перенастроить на http, да и не нужно, если можно прозрачно редиректить.)

Геморрой даже лишняя букова s из себя представляет ))


Добавлено:

Class 2 StartSSL для публичного домена будем покупать завтра.
Но в сертификатах я сам ещё пока плаваю... быстро внутреннюю CA не подниму без опыта. Виндовую разве что...

LevT
Ну тогда можно в nginx прописать proxy_pass на https ресурс, клиент с nginx будут общаться по http, а nginx с сервером по https

Цитата:

Собственно вот сразу все примеры...

Это примеры на уровне приложения. Причем по поводу настройки конкретного приложения -апача.
А меня интересует, прежде всего: можно ли иначе переадресовать запросы - на более низком уровне (транспортном или сессионном)?
Если можно, тот как?

Добавлено:

Цитата:

Ну тогда можно в nginx прописать proxy_pass на https ресурс, клиент с nginx будут общаться по http, а nginx с сервером по https

Во-во, это-то сделать я уже додумался.
А вот чтобы юзеры заходили на один общий https: портал и оттуда уже переадресовывались куда надо - сильно ли сложно?
И извне чтоб это выглядело бы единым порталом. Такой типа SSL VPN

LevT
Собственно делаете свой портал https://example.com и настраиваете его как ssl server в nginx, а дальше описываете proxy_pass понравившихся контекстов (/internal1 /internal2 ...) на соответсвующие внутрение ресурсы, и не важно какие они внутри ssl или нет.

Спасибо! Отлично!

А разумно ли повесить на нгинкс сам небольшой портал (для начала просто несколько статических ссылок) - или надо ставить туда же апач?

LevT
На кой Вам там еще и apache сдался-то...
Просто nginx'у указать:
location / {
root /var/www/dummy/;
index index.html;
}

Добавлено:
OMG!
Ну ладно M$ проплатил слова сервр и microsft, но apach-то за что?

Цитата:

FingerPrint ни как не связан с авторизацией по сертификату, это защитный механизм, запоминания "образа" сервера, что бы при повторном подключение клиент узнал, если кто-то хочет провернуть MITM, поэтому при первом подключение к серверу стоит внимательно отнестись к занесению его отпечатка в свою базу знаний (а то вдруг уже кто-то ждёт тебя, и хана твоему серверу).
На opennet'е есть неплохая статья по authorized by key.

Немного углубился в тему сертификатов - и обнаружил отсутствие интероперабельности OpenSSH с мелкомягкой PKI и вообще X.509.

OpenSSH сейчас активно патчится на сей предмет, но хз когда этим можно будет пользоваться.

https://fogbugz.bitvise.com/default.asp?WinSSHD.1.17397.1




Добавлено:

А вот мелкомягкий SSL сразу понимает эти поганые сертификаты.

Жизнь админа сцукоупрощает... Сначала усложнив до предела самой этой X.509 поганью ((

LevT
Собственно мне не нужно использовать X.509 сертификаты в OpenSSH. Единственное удобство которые я здесь вижу, это если админ этот же X.509 сертификат еще использует где-либо (например, клиентская авторизация на сайте по сертификату). WinSSHD хм... Впервые слышу, зачем оно если есть RDPv6?

p.s.
Цитата:

интероперабельности

блин, есть обычное слово - совместимость...

Добавлено:
И вообще RSA это по сути ключ, а X.509 именно сертификат...

Цитата:

WinSSHD хм... Впервые слышу, зачем оно если есть RDPv6?

Это всего лишь страничка с перечислением ссылок по заинтересовавшей меня теме.

А на PDPv6 похоже придётся задержаться - именно из-за отсутствия комфортно администрируемой PKI в юниксах ((



Цитата:

блин, есть обычное слово - совместимость...

э-ээ, не просто. Совместимость это общее "философское" понятие, интерперабельность его специальный вариант (взаимодействие разнородных вычислительных систем, именно в рантайме).



Цитата:

вообще RSA это по сути ключ, а X.509 именно сертификат...

X.509 - один из многих возможных контейнеров для ключа, да ещё и подписанный авторитетом, который типа (вроде как, а на самом деле хрен - потому что коммерческие CA отмазываются от ответственности) удостоверяет принадлежность публичного ключа лицу. Соответственно, тащит за собой безумный оверхед, с коммерциализацией и тотальным контролем.

Только что в википедии обнаружил академический концепт SPKI - где принципалами безопасности выступают сами публичные ключи. И концепт Ceremony - расширение понятия протокола. Оказывается, последний даже уже реализован... в UPnP.

http://world.std.com/~cme/html/spki.html

Цитата:

Собственно мне не нужно использовать X.509 сертификаты в OpenSSH.

Блин, только несколько часов назад до меня допёрло, что OpenSSH и OpenSSL вещи разные. Но нет худа без добра: вчера я заставил себя подробно пролистать книжечку, которая определённо в будущем пригодится

SSH Mastery OpenSSH, PuTTY, Tunnels and Keys   by Michael W Lucas

LevT
Цитата:

Блин, только несколько часов назад до меня допёрло, что OpenSSH и OpenSSL вещи разные.

лучше поздно чем никогда...
А OpenSSL вообще весьма мощная утилита, рекомендую если не особо углубляться в неё, то хотя бы знать на что она способна.

Alukardd
А в чем её могучесть - кроме поддержки клятого X.509?

Мелкомягкие уверенно прут дальше (могут себе позволить, как богатые и здоровые) с claims-based identity. Которая очень похожа на исследования по ссылке в моём прошлом посте.

А линуксоиды топчутся на одном месте и дублируют проделанную в соседней песочнице работу ((


Добавлено:

Особенно "порадовала" фичастая фича OpenSSH: способность заменить OpenVPN

LevT
Цитата:

Особенно "порадовала" фичастая фича OpenSSH: способность заменить OpenVPN

а что Вам не понравилось? С OpenSSH можно по разному изголяться :-D Но вот туннель он создаёт очень медленный, увы.

OpenSSL помимо того, что реализует кучу механизмов шифрования, кодирования и хэширования, он так же может выступать в качестве ssl клиента/сервера, проверять сертификаты (в т.ч. и цепочки) и т.д.

Сертификаты, "удостоверяющие личность" принципала безопасности - зло, причём абсолютное. Публичный ключ сам по себе годный принципал.

Лучше бы линуксоиды сваяли свою иерархию доверия снизу вверх, чем как сейчас плелись в хвосте коммерческих CA.


Добавлено:

Цитата:

OpenSSL помимо того, что реализует кучу механизмов шифрования, к

ну это просто криптобиблиотека, тысячи их. Хорошо бы ею ещё и пользоваться полезным образом, а не только подражать Злу из последних сил.


Добавлено:

Цитата:

Сертификаты, "удостоверяющие личность" принципала безопасности - зло, причём абсолютное. Публичный ключ сам по себе годный принципал.

Иными словами аутентификация объектов реального мира - категорически не дело софта. А вот авторизацию доступа к разнообразным комп. ресурсам можно и нужно сделать не столь запретительно сложной в администрировании.

Чтобы люди сами управляли количеством и качеством своего доверия сбербанку, киви, гуглояндексам и прочим провайдерам и вендорам - а не записывались к тем в анальное рабство от безвыходности.

LevT
OpenSSL больше чем просто криптографическая библиотека.

Что Вам не нравится в текущем положении дел с сертификатами? Ну разве что зависимость всех от того или иного CA.
Ну давайте создадим сеть доверия из PGP ключей... Я, кстати, не понимаю почему их практически не используют, за исключением подписи репозиториев и изредка писем.

Я за промежуточный вариант, который почему-то никогда и никем не рассматривается. Сеть доверия имеет смысл между теми, кто способен самостоятельно управлять ключами и отвечать своей репутацией перед пирами.

А для большинства "обычных людей" - полное доверие кому-нибудь вот такому, кто возьмётся это делать за них. И легкость смены "патрона". "Найди себе имама или сам стань имамом" (с)

Стать "имамом", при наличии мотивации, должно быть достаточно легко - а не запретительно сложно как сейчас.


Добавлено:

Эта модель прекрасно масштабируется на сегодняшнюю реальность с размножающимися в каждом доме девайсами. Для всех моих девайсов должен быть единственный авторитет, подконтрольный их хозяину - а не гуглояндексам, вконтктикам-нокиям и прочим мелкоэплам.

LevT
Ну так и используйте самоподписные сертификаты или создавайте свой внутрекорпоративный CA.

Расходы по управлению сложностью, навороченной в интересах "корневых" СА и стоящих за них штатовских агентств - за каким хреном я должен нести?

Почему бы не отрезать нахрен нужное только проприетарщикам?

LevT
Щито-то я перестал понимать тебя (не впервые, кстати)...

Alukardd

Сама модель X.509 CA - изначально ущербна по дизайну. Потому что делалась не в наших человеческих интересах, а в интересах спецслужб Страны Абсолютного Добра (о добрых-добрых корпорациях, способных содержать штат выдрессированных на её обслуживание специалистов безопасности - тоже не сильно при этом заботились: они свой профит поимели только между делом)

Ну да, поднапрягшись можно завести дома корневую CA - но в маловероятном случае реального успеха (то есть полезного для себя использования хотя бы 20% её функций) только и останется наниматься в одну из таких корпораций, чтобы применить полученные знания и опыт - потому что людям подобный подвиг как правило не под силу. Не с кем будет даже обсудить результаты.

У тебя у самого примерно тот же мотив был, когда ты отказался от идеи поднимать на новой работе SAN: технология кажется запретительно сложной, боишься не справиться и оказаться в одиночестве наедине с проблемами.


Ситуация аховая в обоих случаях. Линуксоидов, особо любящих "контролировать свои компьютеры", одинаково поимели и развели (ещё и отключив у них критическое мышление). Как так вышло - достойно отдельной работы над ошибками.

Потому что, и SAN (управление кроссплатформенным блочным IO), и управление доверительными отношениями - сейчас уже ключевые области, без которых "контроль над своими компьютерами" возможен только в сопливых мечтаниях.

LevT
Не, у меня есть огромное желание поиметьсся с SAN. Технология запретительно дорогая, и её применение не оправдано ну ни как в моей ситуации.

CA позволяет мне по каким-то "устоям" доверять тому или иному ресурсу, на основе общих убеждений в нерушимости и праведности CA. Можно юзать DNSSEC. Для своих домашних нужд я использую самоподписные сертификаты.