Автор Тема: Криптографска библиотека  (Прочетена 4710 пъти)

4096bits

  • Участник
  • *****
  • Публикации: 3178
    • Профил
Re: Криптографска библиотека
« Отговор #15 -: Mar 24, 2016, 15:27 »
И аз се притеснявам от mitm, но това .... не зная, как до го избегна. Ще търся още в нета. И за това. Точно пращането на ключа от сървъра, ако ще е сървър, на клиента, преди клиента да върне своя обратно, но вече криптиран. Ама са съм зает с други неща, та поне няколко дена до тогава
Активен

As they say in Mexico, "Dasvidaniya!" Down there, that's two vidaniyas.

Naka

  • Участник
  • *****
  • Публикации: 2641
    • Профил
Re: Криптографска библиотека
« Отговор #16 -: Mar 25, 2016, 11:06 »
И аз се притеснявам от mitm, но това .... не зная, как до го избегна.

Изобщо има ли начин да се избегне mitm без посредничеството на трето лице - който да сертифицира подписите?

И аз бях изправен пред такава дилема, накрая го направих с RSA, примирих се с възможността че може да има mitm. Тъй де вместо да давам луди пари за сертификати, примирих се с риска, пък и данните ми не са кой знае колко важни.

http://www.linux-bg.org/forum/index.php?topic=45658.0
http://www.linux-bg.org/forum/index.php?topic=46769.0
И сега всичко работи без грешка.


« Последна редакция: Mar 25, 2016, 11:16 от Naka »
Активен

Perl - the only language that looks the same before and after encryption.

growchie

  • Участник
  • *****
  • Публикации: 622
    • Профил
Re: Криптографска библиотека
« Отговор #17 -: Mar 25, 2016, 20:28 »
https://en.wikipedia.org/wiki/Kerberos_(protocol)

Другият вариант е сам да си поддържаш сертификейшън ауторитито и лично да инсталираш ключовете по клиентите. Не виждам проблеми изобщо.
« Последна редакция: Mar 25, 2016, 20:33 от growchie »
Активен

gat3way

  • Участник
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Re: Криптографска библиотека
« Отговор #18 -: Mar 26, 2016, 02:33 »
Ужасно е досадно подържането на CA, поне от скромния си опит, доста ограничен до само няколко хоста. Тогава ползвах xca, не знам сега дали има нещо по-удобно и красиво. С конзолните tool-ове на openssl е....мех, трябва да си ненормален / най-малкото да изпишеш прилично скриптове да ти организират нещата. Като по-млад и по-глупав обичах да се изцепвам че работата на CA-тата е лесна и правят пари от нищо, обаче далеч не е така, в такъв мащаб като техния това е доста комплексна и досадна кочина. Извън всички одити, процедури, клиентски там фронтенди, OCSP и timestamp verification инфраструктура и прочее дивотии, изискванията към CA-тата са брутални. Например на "най-най-root" сертификата, частният му ключ не се пази на никой хост, а е split-нат на няколко физически носители, които стоят в различни сейфове до които имат достъп различни хора - оттам надолу по веригата следващите като тръгнат да изтичат се събират хората, вадят флашките и подписват следващият генериран csr, процесът се документира надлежно....и машината на която е подписан intermediate сертификата....се разрушава, защото знае ли човек може някъде по случайност да остане събрания ключ. Това съвсем сериозно, такава параноидна шизофрения е там и такива са им процедурите.

Та нуждата от доверена трета страна определено е нещо което бърка в задника...обаче не мисля че има адекватно решение, което да се скалира добре, в смисъл може и без доверена трета страна разбира се, но това става в ограничени мащаби точно както примерно можеш да си набиваш и хостове в /etc/hosts и това работи в ограничени мащаби, иначе много скоро стигаш до нуждата от DNS протокола.

То не е и толкова технически въпрос, колкото не знам, логически/философски там. В реалният живот е същото, затова примерно като някой прави нещо вместо теб с пълномощно, обикновено го искат нотариално заверено....защото на този някой не му вярват, но на нотариуса му вярват. Въпросите с доверието са винаги такива забавни, защото хората както имат навика да лъжат, така имат навика и да се доверяват на базата на някакви ирационални критерии, а пък абсолютно всичко си се гради на доверие - обществения строй, икономическата система, всичко можеш с добро желание да го сведеш до отношения на доверие.  И оттам съществува и ирационалното схващане че технически тези неща могат да се решат някак си, спестявайки си съвсем логическите дилеми. Само че поне досегашният опит показва че не стават толкова лесно нещата.

Иначе кандидати да се замени PKI като идея има, не като да няма, примерно разни IBE схеми, само дето и там има трета доверена страна, там някои (скъпи) проблеми се решават, други (неприятни) проблеми се въвеждат. При kerberos понеже се спомена, сървърът дето издава ticket-ите e и третата доверена страна. Чувал съм разни екзотични идеи, като например ползването на нещо подобно на блокчейна в биткойн като убиец на PKI и CA инфраструктурата и там идеята за доверената трета страна е леко размита. Обаче на мен ми се вижда като цяло глупаво хрумване, ма па знам ли - може да се доразвие и да добие смисъл.
Активен

"Knowledge is power" - France is Bacon

Naka

  • Участник
  • *****
  • Публикации: 2641
    • Профил
Re: Криптографска библиотека
« Отговор #19 -: Mar 26, 2016, 11:32 »
При военните има понятието офицер за свръзка. Т.е. може да му се даде ключа/шифъра и той да го занесе на отсрещната страна.

Обаче в случая офицера за свръзка пак се явява като трето доверено лице или като секюрити канал - в зависимост от интерпретацията.
« Последна редакция: Mar 26, 2016, 11:34 от Naka »
Активен

Perl - the only language that looks the same before and after encryption.

spec1a

  • Участник
  • *****
  • Публикации: 1039
    • Профил
Re: Криптографска библиотека
« Отговор #20 -: Mar 27, 2016, 10:40 »
   Не мога да разбера какво толкова ви притесняват т.нар.  mitm  атаки.
Нали лесно може да се види,че отсрещния ip адрес не е тоя,който трябва
(ще се вижда този на атакуващия).Лесно се вижда с  tcpdump или
 wireshark.
   Ако адреса не е "правилния" , връзката се блокира.
   Може да се напише скрипт, или да  се използва  iptables и т.н.
Активен

BRADATA

  • Участник
  • *****
  • Публикации: 833
  • Distribution: Slackware/Mint/CentOS
  • Window Manager: console/KDE/LXDE
    • Профил
    • WWW
Re: Криптографска библиотека
« Отговор #21 -: Mar 27, 2016, 14:44 »
   Не мога да разбера какво толкова ви притесняват т.нар.  mitm  атаки.
Нали лесно може да се види,че отсрещния ip адрес не е тоя,който трябва
(ще се вижда този на атакуващия).Лесно се вижда с  tcpdump или
 wireshark.
   Ако адреса не е "правилния" , връзката се блокира.
   Може да се напише скрипт, или да  се използва  iptables и т.н.
Ти нали не си сериозен? В локалния сегмент съществуват много начини да пренасочиш всичкия трафик през теб без никой да разбере (потърси, ще намериш тонове информация), а ако трафика се рутира - става още по-лесно :)
Активен

gat3way

  • Участник
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Re: Криптографска библиотека
« Отговор #22 -: Mar 27, 2016, 16:04 »
Цитат
   Не мога да разбера какво толкова ви притесняват т.нар.  mitm  атаки.
Нали лесно може да се види,че отсрещния ip адрес не е тоя,който трябва
(ще се вижда този на атакуващия).Лесно се вижда с  tcpdump или
 wireshark.
   Ако адреса не е "правилния" , връзката се блокира.
   Може да се напише скрипт, или да  се използва  iptables и т.н.

Това не работи така. Той TCP стека по принцип няма да"асоцира" с връзката пакет идващ от друг IP адрес и съответно нищо няма да се изчете от сокета, така че няма нужда от iptables правила. Обаче както BRADATA спомена, в същия етернет сегмент не е проблем да се правиш на който и да е, решенията срещу тези проблеми (порт секюрити, 802.1x) не са толкова евтини и лесни за прилагане. Ако трафикът се рутира през инфраструктура контролирана от лошите (да речем доставчика ти), тогава също няма как да знаеш с кого си говориш, всичко ще изглежда нормално. Дори не говорим за големите конспирации - претуриране на чужд трафик чрез BGP измами, tap-ване на оптични кабели и съвсем "легално" разположената из разни IX-ове и tier1 телекоми техника за слухтене и селективно mitm-ване на разни врази там.
Активен

"Knowledge is power" - France is Bacon

growchie

  • Участник
  • *****
  • Публикации: 622
    • Профил
Re: Криптографска библиотека
« Отговор #23 -: Mar 27, 2016, 16:47 »
Вземаш си флашката и си разменяш удостоверителните сертификатчета на ръка. Или звъните по телефона и си обменяте публичните ключове по факс...
Активен

spec1a

  • Участник
  • *****
  • Публикации: 1039
    • Профил
Re: Криптографска библиотека
« Отговор #24 -: Mar 27, 2016, 22:27 »
   Добре де,приемаме ,че много печен хакер е прихванал ключовете и т.н.
   Ако обаче се използват ТАН-ове (някои банки ги използват в интернет
банкирането си),предварително договорени последователности от числа,
хакера тогава нищо не може да направи (няма как да знае следващото
число),тогава ще трябва да хакне сървъра ,или някой клиент.
   Подобна имплементация според мен е доста сигурна.
Активен

neter

  • Global Moderator
  • Участник
  • *****
  • Публикации: 3408
  • Distribution: Debian, SailfishOS, CentOS
  • Window Manager: LXDE, Lipstick
    • Профил
    • WWW
Re: Криптографска библиотека
« Отговор #25 -: Mar 28, 2016, 12:19 »
Ужасно е досадно подържането на CA, поне от скромния си опит, доста ограничен до само няколко хоста. Тогава ползвах xca, не знам сега дали има нещо по-удобно и красиво.
Аз поддържам едно CA в офиса с TinyCA2. Препоръчвам го, ако на някого му се наложи да прави такова нещо, макар че и той си има неща за доизкусуряване. Но не обещавам да е по-малко досадно :)
« Последна редакция: Mar 28, 2016, 12:24 от neter »
Активен

"Да си добре приспособен към болно общество не е признак за добро здраве" - Джиду Кришнамурти

gat3way

  • Участник
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Re: Криптографска библиотека
« Отговор #26 -: Mar 30, 2016, 02:08 »
Изглежда по-красиво ако не друго :)

Цитат
  Добре де,приемаме ,че много печен хакер е прихванал ключовете и т.н.
   Ако обаче се използват ТАН-ове (някои банки ги използват в интернет
банкирането си),предварително договорени последователности от числа,
хакера тогава нищо не може да направи (няма как да знае следващото
число),тогава ще трябва да хакне сървъра ,или някой клиент.
   Подобна имплементация според мен е доста сигурна.

TAN-овете са средство за автентикация, не за осигуряване на конфиденциалността на комуникацията, но да речем може лесно да се пригоди вместо поредни номера, по сигурен канал да се разменят направо поредица сесийни ключове. Ключове ще предоставя, но иначе тъй като проблемите са различни и има различни изисквания, ще има други драми. Например, само по себе си пак няма да реши проблема с replay атаките - да хванеш и да изпратиш същото (криптирано) съобщение втори път. Няма да ти реши проблема с елементарната DoS атака ако имаш някой в средата който нарочно да модифицира съобщения, да ти "изхаби" целият договорен списък със сесийни ключове и да те прати пак по бюрократичните мъки. Ти също така никога няма как да знаеш с кого си говориш - освен по това че криптираните съобщения, които ще ти праща са пълен булшит ако той не знае ключа, но този пълен булшит може и да се интерпретира по някакъв начин, все пак машините са тъпи и поемат каквото им дойде. За последното има решение ако се ползва автентицирано криптиране или HMAC, така че това да речем не е големият проблем.

Големият проблем както казах е че това няма да скалира добре. В случаят с банкирането си улеснен - първо защото се предполага че можеш да си го вземеш от твоя банков клон срещу молба и лична карта и цялата бюрокрация, която е чисто "човешка" работа. Подобен лукс обаче трудно би могъл да имаш ако примерно разработваш приложение за криптиран чат (представи си сходна схема, само че със скайп примерно). И просто е неудобно. Ако искаш представи си го като HTTPS сайт за който вместо да се доверяваш на цялата CA йерархия там, ходиш и изискваш отнякъде (дали на крака в офис, дали по пощата) списък с ключове. Докато не ги получиш (и това отнема време), не можеш да се свържеш. Като ги изчерпаш, съответно същата процедура. Хората биха намразили нещо такова :)
Активен

"Knowledge is power" - France is Bacon