0 1
Аве, верно ли има хора, които не намират смисъл в TLS-a? Прочетох цялата тема... останах потресен... https://forums.bgdev.org/index.php?showtopic=51107
Второразрядните форуми не са интересни...
Ами лично моето отношение към TLS е малко двойнствено. Да, когато става въпрос за аутентикация, пароли, чувствителни данни и комуникация между хора е ясно, че е задължително.
Но от друга страна, въвеждането на шифроване, сертификати и др.под. много силно повишава изискванията към хардуера и софтуера. Ако обикновеният HTTP може да се поддържа и от най-слабият контролер, то с намесата на криптирането летвата се вдига много високо. И за клиентите и за сървърите.
Все пак, криптираната връзка е на порядък по-надеждна. Което и накланя везните в крайна сметка.
You mad? Всеки x86 от поне 10 г. може да криптира AES със скорости от GB/s, същото вече могат и ARM с Neon. Колко MB да ти е интернет канала на клиент? 10? Значи хабиш 2% CPU за целия канал всички сайтове едновременно, примерно.
Аз криптирам всичко. Занимавам се с финтех, не мога да си позволя да не го криптирам. Даже исках да въведа смарт контракти за OTP, но не ми дадоха, че имало по-важна работа. Но ако говорим за каквото и да е, което е вързано с Интернет, трябва да има чейн оф тръст, точно както са го измислили. Те доказват, че аз съм аз. МВР са ауторити и ми издават лична карта с уникален номер. Аз съм аз. Иначе тук съм курвоазие, ху дафак е тоя унтерменш? И не само ако има чувствителни данни. Ако съм на HTTP и някой ме отвори от хотел, а някой друг е компроментирал ДНС-а на хитела и го пренасочи другаде, там има някакъв фейк, някой му краде пари, на теория виновен си е задклавиатурния, но на практика в УСА може и да ме осъди. Ще навреди на репутацията ми ако се разчуе. ЗКУ-то може и да е идиот, но трябва да го обслужа, така че да е доволен и да си даде пак парите при мен. Със сертификат му доказвам, че съм аз. Да, микроконтролерите са слаби за това, някой от тях доста. Други не, зависи. Ако мога пак бих криптирал. Ако не, то тогава трябва архитектурно да го замисля трудно, както и физически.
Абе, слаби, слаби... ардуино не съм пипал. Распберито се справя. Попал съм AVR-и в даскало, но там с микрос/ос2, риъл тайм, въобще мрежи сме нямали. А ако ми се наложи бих измислил поне някаква енкрипция, ако трябва и симетрична. Щото сме параноици, в момента използвам HMAC чексума, сървърен и клиентски сертификати и за някои операции генерирма симетричен ключ, който си пращаме криптиран от асиметрични ключове, които генерираме на момента. И си имаме firewall-и всякакви. Просто трябва да е много трудно да ни хакнат, защото сме под надзора на едни дебели организации, лоито ако кажат, че не сме надеждни или т.н. то вече няма да имаме бизнес. За мен не е проблем, не е мой, но пък ми е полезно като опит.
Забравих да кажа - първо компресирам, после криптирам, после и хеширам, да се знае, че аз съм аз. Има ксеони, ще бачкат!
Абе имаше некви драми с компресия + криптиране, лиикваше някаква информация, те затова направиха HPACK специално за хттп2
Аз лично бих ползвал само нещо готово като TLS или Noise със X.509 серификати за PKI и така като гледам щом още ползваш “хеширане” извън AEAD cipher значи и на теб ти го препоръчвам.
Btw компресирането отпадна като опция от TLS защото намалява надеждността последно.
Интернет модълът на алармата ми на практика не работи ако му включа https. Ксеони самолети и ракети, ама на мен ми е важно паролата на алармата да не се вижда през нета. И греда, не баца криптирано.
Криптирането е хубаво нещо, но да ти се набутва готова схема как да се прави е определено "гнила ябълка". Защо няма технология за разработка на индивидуални криптиращи алгоритми, които ако искаш след това за по-голяма сигурност да ги навържеш след стандартните използвани. Тези нестандартни алгоритми да можеш лесно да ги теглиш примерно от сайта на този, който ги разработва, като разчиташ на сигурността на стандартните алгоритми или да си ги вземеш по друг по-чист начин (физическо закупуване на носител).
Не си в час. Алгоритъмът AES е симетрична крипто система и точно това е изискването при реализацията й - максимална скорост, добро омазване на криптираните данни и сравнително малко изчисления, за да се извърши това. Но HTTPS не залага САМО на симетрично криптиране, защото преди това трябва да се обмени ключа, който вече се предава с а-симетрична крипто система, което е вече многократно по-сложен алгоритъм базиран на дебела математика. Той е и много по-бавен, но това вече не е фактор в конкретния случай.
Реба Създадено на 27.07.2020, видяно: 1545 пъти. #774
в компютърния бранша има доста странни неща, и търсенето на рационална причина е загубана време, просто всички в калифорния са откачени педали, а калифорния е компютърджийската мека. така че не търсете смисъл във всяка глупост която се е "наложила"
Как така да не търсим смисъл??? Ами тогава на каква друга тема да тролим?
Компресия + Криптиране защо да е лошо? Виждал съм го на поне няколко места като препоръка - компресия и после AES 256 на пейлоуда (да не е CFB, да е поне CBC), а след това initialization vector-а и passphrase-a да са RSA-нати. Идеята на компресията е да се намалят повтарящите се данни, redundancy. Това е за payload-а на ниво HTTP; отделно client-server си енкриптват на ниво TCP (TLS, като е добре да се настроят разрешените Cypher-и ръчно, защото някои не са толкова надеждни). AES-256 за пейлоуда, защото е по- бързо от RSA, а RSA за ключа и вектора на AES-а.
HMAC-a е за подпис, за да може на по-високо ниво да се знае, че клиентът е клиент. Например, стандартно е да взема 2-3 параметъра + нещо променливо и да генерирам HMAC Signature. Пеймънт провайдърите, с които съм се интегрирал го имат, дори и на респонса. Правя го на клиента и го повтарям на сървъра. Да го правя така ми е гайдлайн на някакви Security компании, нямам много избор. Сървърният сертификат ясно, а клиентският е също за ауторизация на клиента, но на ниво TCP. Всичките тези сертификати винаги може да се revoke-нат от CRL-а.
ПС: Изобретяването на криптиращ алгоритъм е нещо доста математическо, не можеш да очакваш всеки да може да го направи. За да може всяка маймуна да го имплементира е необходим стандарт и пак им е трудно.
Намаля данните, които ще се компресират. Зависи какво компресираш. В крайна сметка, сървъра прави компресия, после криптиране, връща към клиента, а клиента го де-прави в обратня ред.
ПС2: Още за математиката, пробвали ли сте да обяснявате на джуниъри elliptic curve diffie-hellman и да ги гледате как мигат :D
Те там пишат на някакви екзотични езици, не са корпоративни като нас, на .net и java :D Понеже са гееве и имат no life, то тогава имат време да се мъчат. Аз искам нещо стандартно, да му стане ясно на друг след мене, да ми стане ясно и на мен като дойда след някой друг. Колкото и да ми казват, че хардуера е евтин, виждам, че именно най- много време отива в оправянето на нечий лайна и последен левел съпорт. В която и фирма да съм бачкал, най- много оправям нечии умствени пърдежи, включително и мои такива, когато съм бързал за някакви имагинерни срокове.
Личи си че си книжен плъх без реално да си пипал TLS отдолу. Ключ не се обменя вече а се синтезира (key derivation) на база HKDF в последната версия на TLS, като вече input key material ти е нещо разнообразно вкл. shared secret от ECC-то дето твърдиш, че е бавно. Мерил ли си го колко е бавно? Не говоря за 8192-битов RSA а за secp256r2 примерно нещо като за 128-битово секюрити.
В TLS 1.3 няма DH дори, като всичко е ECC с ephemeral keys. Сертификатите са развързани от traffic криптирането и се ползват само за auth което и трябваше отдавна да се направи.
Баси, покопал си. Кажи некоя фирма в България, къде го бачкат това. Само софтсърв, онези украинците, ме питаха на интервю как баш TCP работи и как баш TLS работи, за някакъв solar нещи си проект беше, но day-to-day не им се налага. А и там не бих бачкал, беше ми интересно просто самото интервю. Аутсорса го зарязах, не искам да се връщам. За да влезна в такива неща трябва да си чета дома.
Аре, да доказвам на секюритито, че не могат да си ползват application firewall-а и кое точно къде зависа съм копал, признавам си. И с wireshark, и с curl.
Curl-a e много як инструмент. Казах на този форум, иска ми се HTTP/2 с TLSv1.3, обаче форумът ми каза да ползвам HTTP/1.1 с TLSv1.2/ Е ти тоя сайфър. Стискаме си ръцете. Вземи тоя текст, който е HTML, CSS и JS.
curl -v https://bgdev-free.asm32.info
* Trying 209.250.243.170...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x7fffd0113f50)
* Connected to bgdev-free.asm32.info (209.250.243.170) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=asm32.info
* start date: Jul 21 20:16:57 2020 GMT
* expire date: Oct 19 20:16:57 2020 GMT
* subjectAltName: host "bgdev-free.asm32.info" matched cert's "bgdev-free.asm32.info"
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
> GET / HTTP/1.1
> Host: bgdev-free.asm32.info
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx
< Date: Mon, 27 Jul 2020 09:15:03 GMT
< Content-Type: text/html; charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Vary: Accept-Encoding
< X-Frame-Options: SAMEORIGIN
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< Content-Security-Policy: default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'; img-src https: data:
< X-Xss-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< Referrer-Policy: no-referrer-when-downgrade
0 1