Linux за българи: Форуми

Какво да използвам за криптиране на комуникация по мрежата? Става въпрос за python-ки код. Одеве попаднах на nacl, но понеже не съм се занимавал никога с криптография, та се чудя, какво да използвам.

Това би трябвало да е от предпоследните въпроси, няма особено значение каква библиотека използваш, далеч по-важно е какво ще правиш.

Грубо казано, представи си че трябва да окабелиш някоя сграда и да сложиш там суичове, рутери и аксес пойнтове, еквивалентният въпрос би бил каква марка кримпвачка да ползваш.

Ам, нищо особено. Комуникация между клиент и сървър, две или повече приложения. Може би и през интернет.

Че това си е доста. Например откъде ще се взема ключа за криптирането. Само конфиденциалността ли е цел, интегритета на данните важен ли е, някаква форма на автентикация между двете страни ще има ли или те ще си вярват една на друга по подразбиране - тези неща не са нищо особено.

Защита на комуникация. Нещо ми се въртеше в главата, да се генерира частния и публичния ключ от едната страна, да се изпрати публичния ключ на другата страна и тя да генерира също частен и публичен и да върне собствения публичен, криптиран с получения преди това от първия адрес ключ. Ама колко работи и какво криптиране да ползвам не ми е ясно. Нещо като сървър клиент. И евентуално комуникация само между "клиенти", без сървър. Може и повече от два броя да са. Или симетрично криптиране?

Ми тя такава схема би била податлива на MitM атака - примерно аз стоя по средата и първоначално раздавам на двете страни моя публичен ключ, вместо да им препредам публичните ключове които са изпратили - оттам нататък всичко което минава като комуникация ще мога да го декриптирам. Всъщност, ще мога дори да криптирам каквото ми изнася с моя частен ключ и да го предам нататък, вместо да препредам оригиналното съобщение, то ще си изглежда съвсем легитимно.

Пробвай го NACL, уж е по дизайн направена да се избегнат по-голямата част от грешките от програмисти. Имаше и python библиотеки - pynacl (по спомени говоря)

Аз и за тази питах в самото начало, но понеже преди десетина дена разбрах окончателно, какво е частен и публичен ключ и как работи изобщо тази асинхронна крипто щуротия, питам за съвет, ако някой се е занимавал. Та асинхронно криптиране или синхронно да гледам? И по-важно ми е, кое от всичките видове може да дате някаква по-сносна сигурност. Че доколкото разбрах, някои вече се смятат за не дотам надеждни.

Ето ти за libnacl elliptic curves лекцията - https://www.youtube.com/watch?v=l6jTFxQaUJA

А защо не Diffie-Hellman с нещо като Station-to-Station протокола ($2) и сертификати?

Така имаш ephemeral ключове, съответно perfect forward secrecy (компрометирането на частния ключ на една от страните не води до осуетяване на цялата предишна комуникация), пък и защита от MitM.

Не знам обаче има ли готови решения.

Diffie-Hellman без значение дали е с фиксирана или с ефемерна публична стойност, по дефиниция е податлив на mitm атаки, т.е ако някой стои между двете страни няма никакъв проблем да представи собствена публична стойност, сметките да минат и да сдоговорят с двете страни два, макар и различни, но известни на атакуващият сесийни ключове.

Сега ако въпроса е защо след като е уязвим въпреки всичко се ползва в TLS или SSH протоколите примерно, това е защото не се ползва само DH, малката тайна е че сървъра там подписва публичната си стойност и клиентът проверява сигнатурата, при това положение няма как някой по средата да мами. Обаче това вече влачи и последствията като например нуждата клиента да има налични публични ключове (или сертификати) срещу които да проверява дали това отсреща е сървъра с който иска да си говори или не, и тези трябва по някакъв сигурен канал да му бъдат доставени. В случаят с SSH това обикновено не се случва (първият път когато се връзваш ти се вади fingerprint-а на сървърния ключ и ако искаш връзваш, ако не искаш - не - но ако вържеш оттам нататък се помни и при промяна реве). Сега обаче в 99.999% от случаите на никой не му пука да проверява това, което е разбираемо - излишна параноя, а човек бърза да си свърши работата в крайна сметка.


Та както и да е - оттук и идея - няма ли да е далеч по-лесно да ползваш готова (и доказана) TLS имплементация, вместо сам да си измисляш криптосистема (което не е лесно и е твърде вероятно да се оплеска) ? С PyOpenSSL примерно не е толкова сложно, има и примери из нета. "Стандартната" ssl библиотека на питон е дори още по-лесна за ползване, единствено не дава достъп до разни неща, които с много голяма вероятност изобщо няма да ти трябват.

А не можем ли да разменим сертификатите в самия процес на DH handshake-а?


Където EK е крпиптираната (с вече установения чрез DH ключ) сигнатура на двата експонента, разписана с private key-я на съответната страна.

Човекът по средата няма какво да направи, защото дори и сертификатът да е самоподписан и да го смени със свой, EK(SB(експоненти)) са разписани с частен ключ, кореспондиращият на който публичен няма да е този в подменения сертификат на атакуващия.

Ми ти на 2) нямаш вече установен чрез DH ключ. В смисъл кой ти е казал че е установен, аз поне не бих се съгласил особено в mitm сценария.

Малко сложно почнахте да ми говорите. Интересува ме основно следното. Как да разменям съобщения между два адреса в локална или интернет. Та било клиент/сървър или просто между два и повече клиенти. Програмите да си общуват една друга. Питах, коя библиотека и какво криптиране да ползвам, които да са относително сигурни. А връзката почти сигурно ще върви по ssl, ssh или там, каквото ще да е. Но в случай, че се счупи, да не лъснат данните дето хвърчат в "прав текст", а да му се наложи на някой години да хвърля камъни, преди да слупи криптирането.
То връзката между клиентите или сървъра и клиентите лесно да се направи и си играх тук. От тук нататък не зная, коя точно от всички крипто-магии да порбвам да вмъкна помежду трафика.

Имам един познат, който бачка за mega.nz. Та той твърди, че те бягат като дявол от тамян от openssl. Предпочитат gnutls или libressl. М-у другото освен файлове, се занимават и с криптиран чат и видео. Може да ги потърсиш в github-а. Пуснали са си целия сайт FLOSS. meganz им е акаунта там.

И аз се притеснявам от mitm, но това .... не зная, как до го избегна. Ще търся още в нета. И за това. Точно пращането на ключа от сървъра, ако ще е сървър, на клиента, преди клиента да върне своя обратно, но вече криптиран. Ама са съм зает с други неща, та поне няколко дена до тогава

И аз се притеснявам от 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
И сега всичко работи без грешка.

https://en.wikipedia.org/wiki/Kerberos_(protocol)

Другият вариант е сам да си поддържаш сертификейшън ауторитито и лично да инсталираш ключовете по клиентите. Не виждам проблеми изобщо.

Ужасно е досадно подържането на CA, поне от скромния си опит, доста ограничен до само няколко хоста. Тогава ползвах xca, не знам сега дали има нещо по-удобно и красиво. С конзолните tool-ове на openssl е....мех, трябва да си ненормален / най-малкото да изпишеш прилично скриптове да ти организират нещата. Като по-млад и по-глупав обичах да се изцепвам че работата на CA-тата е лесна и правят пари от нищо, обаче далеч не е така, в такъв мащаб като техния това е доста комплексна и досадна кочина. Извън всички одити, процедури, клиентски там фронтенди, OCSP и timestamp verification инфраструктура и прочее дивотии, изискванията към CA-тата са брутални. Например на "най-най-root" сертификата, частният му ключ не се пази на никой хост, а е split-нат на няколко физически носители, които стоят в различни сейфове до които имат достъп различни хора - оттам надолу по веригата следващите като тръгнат да изтичат се събират хората, вадят флашките и подписват следващият генериран csr, процесът се документира надлежно....и машината на която е подписан intermediate сертификата....се разрушава, защото знае ли човек може някъде по случайност да остане събрания ключ. Това съвсем сериозно, такава параноидна шизофрения е там и такива са им процедурите.

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

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

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

При военните има понятието офицер за свръзка. Т.е. може да му се даде ключа/шифъра и той да го занесе на отсрещната страна.

Обаче в случая офицера за свръзка пак се явява като трето доверено лице или като секюрити канал - в зависимост от интерпретацията.

   Не мога да разбера какво толкова ви притесняват т.нар.  mitm  атаки.
Нали лесно може да се види,че отсрещния ip адрес не е тоя,който трябва
(ще се вижда този на атакуващия).Лесно се вижда с  tcpdump или
 wireshark.
   Ако адреса не е "правилния" , връзката се блокира.
   Може да се напише скрипт, или да  се използва  iptables и т.н.

   Не мога да разбера какво толкова ви притесняват т.нар.  mitm  атаки.
Нали лесно може да се види,че отсрещния ip адрес не е тоя,който трябва
(ще се вижда този на атакуващия).Лесно се вижда с  tcpdump или
 wireshark.
   Ако адреса не е "правилния" , връзката се блокира.
   Може да се напише скрипт, или да  се използва  iptables и т.н.

Ти нали не си сериозен? В локалния сегмент съществуват много начини да пренасочиш всичкия трафик през теб без никой да разбере (потърси, ще намериш тонове информация), а ако трафика се рутира - става още по-лесно :)

   Не мога да разбера какво толкова ви притесняват т.нар.  mitm  атаки.
Нали лесно може да се види,че отсрещния ip адрес не е тоя,който трябва
(ще се вижда този на атакуващия).Лесно се вижда с  tcpdump или
 wireshark.
   Ако адреса не е "правилния" , връзката се блокира.
   Може да се напише скрипт, или да  се използва  iptables и т.н.

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

Вземаш си флашката и си разменяш удостоверителните сертификатчета на ръка. Или звъните по телефона и си обменяте публичните ключове по факс...

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

Ужасно е досадно подържането на CA, поне от скромния си опит, доста ограничен до само няколко хоста. Тогава ползвах xca, не знам сега дали има нещо по-удобно и красиво.

Аз поддържам едно CA в офиса с TinyCA2. Препоръчвам го, ако на някого му се наложи да прави такова нещо, макар че и той си има неща за доизкусуряване. Но не обещавам да е по-малко досадно :)

Изглежда по-красиво ако не друго :)

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

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

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