Nykyselaimet sertifikaattivaatimuksineen tekevät salauksesta ja tietoturvan ylläpitämisestä melkoisen vaikeaa. Kehitän omaa pikaviestintä ( http://sininenankka.dy.fi/~sami/pikaviestin/ ), johon pystyy itse hostaamaan palvelimia. Pikaviestimeen olisi tarkoitus tulla myös selaimessa toimiva web-käyttöliittymä, jossa pystyisi myös soittamaan ääni- ja videopuheluita, kuten natiiviclientissäkin. Nykyselaimet eivät kuitenkaan suostu kaappaamaan mikrofonia tai kameraa, jos yhteys palvelimeen ei ole salattu. Salaukseen liittyy melkoinen määrä ongelmia:
- Jos sertifikaatti ei ole "luotetun tahon" hyväksymä, niin nykyselaimet näyttävät käyttäjälle melkoisen vahvaa kieltä sisältäviä perättömiä väitteitä sisältävän varoitussivun - esimerkiksi Chrome konkreettisesti väittää sivun yrittävän varastaa luottokorttitiedot.
- Lähiverkon IP-osoitteelle ei saa sellaista sertifikaattia, jonka selain hyväksyisi. Selain ei edes tiedä, mitkä ip-osoitteet ovat lähiverkon osoitteita.
- HTTP salataan yksinkertaisesti käyttämällä HTTP-protokollaa TLS-protokollan hyötykuormana. Sertifikaatit assosioidaan yhteen DNS-osoitteiden kanssa, mutta HTTP-palvelin tietää vasta TLS-kättelyn jälkeen, mistä hostnamesta asiakas haluaa hakea sivun (HTTP:n "Host-name"-optio). TLS-protokollassa on SNI (Server Name Indication), mutta siinä DNS-nimi menee salaamattomana, mikä on monessa käyttötapauksessa tietoturvariski.
- Sekä turvallisuuden että itse hostaamisen helpon mahdollistamisen kannalta olisi järkevintä, jos selaimen käyttäjä saisi itse hallita hyväksyttyjä sertifikaatteja ja sertifikaattiauktoriteetteja. Nykyselaimet eivät kuitenkaan sellaista anna tehdä.
Nämä nykyselainten keinotekoiset rajoitteet käytännössä pakottavat käyttämään Discordin kaltaisia keskitettyjä palveluita, joissa kaikki palveluun lähetetty data tallentuu selkokielisinä palveluntarjoajan palvelimille ollen sieltä sitten vapaasti hyödynnettävissä niin mainostajien kuin erinäisten tiedustelupalveluidenkin käyttöön. "Tietoturvan" nimissä siis oikeastaan huononnetaan tietoturvaa.
Oma projekti on täysin jäissä näiden ongelmien takia. Nyt vielä kaiken lisäksi moni selain alkaa vähitellen estämään kokonaan salaamattoman HTTP:n käyttöä, mikä tekee selaimen kautta tapahtuvasta tekstichattailustakin tuolla omalla systeemillä mahdotonta.
Huh huh!
Keinotekoista salausta.
Tiedätköhän nyt oikeasti mistä puhut
Kannattaa ehdottomasti itse tehdä ja säästää
noutti kirjoitti:
Kannattaa ehdottomasti itse tehdä ja säästää
Oma kotiautomaatio ohjelmistoni tulee käyttämään julkisen avaimen autentikointia ja asiakkaan ja viestinvälityspalvelimen välinen liikenne salataan istuntoavaimella. En näe tässä ongelmaa mikäli yksityiset avaimet pidetään ulkopuolisten ulottumattomissa.
Turakointi kirjoitti:
- Sekä turvallisuuden että itse hostaamisen helpon mahdollistamisen kannalta olisi järkevintä, jos selaimen käyttäjä saisi itse hallita hyväksyttyjä sertifikaatteja ja sertifikaattiauktoriteetteja. Nykyselaimet eivät kuitenkaan sellaista anna tehdä.
Jaa itse kyllä viimeksi tällä viikolla asensin oman luotetun juurivarmentajan ja toimi selaimissa ihan kivasti.
Grez kirjoitti:
(07.01.2024 20:23:45): ”– –” Jaa itse kyllä viimeksi tällä viikolla asensin...
Se on vain "keinotekoisesti hankaloitettu tietoturvan nimissä"!
Niin oliko sulla syy, mikset vaikka ota palvelullesi esim. lets encryptillä ilmaista ja luotettua sertiä, tai osta sellaista?
Mitä tulee sisäverkkoon, sinne voit ihan normaalisti rakentaa M2M varmennukset itse allekirjoitetuilla sertifikaateilla.
HTTP-salaus, ja payloadin kryptaaminen/purkaminen erillisillä sertifikaateilla ovat myös eri asioita.
groovyb kirjoitti:
Niin oliko sulla syy, mikset vaikka ota palvelullesi esim. lets encryptillä ilmaista ja luotettua sertiä, tai osta sellaista?
Eikös tuo vaadi domain nimen, mikäli haluaa tuon sertfikaatin automaattisesti pitää ajan tasalla?
Vaatii joo, mutta se nyt on hyvä olla muutenkin olemassa osoitteena jos kerran kyseessä on selaimella käytettävä pikaviestin.
groovyb kirjoitti:
(08.01.2024 10:57:42): Niin oliko sulla syy, mikset vaikka ota...
Itse allekirjoitettua sertifikaattia yrittäessä selaimet näyttävät käyttäjälle pelottavia virheilmoituksia.
Turakointi kirjoitti:
groovyb kirjoitti:
(08.01.2024 10:57:42): Niin oliko sulla syy, mikset vaikka ota...
Itse allekirjoitettua sertifikaattia yrittäessä selaimet näyttävät käyttäjälle pelottavia virheilmoituksia.
Niin, siksi siellä web palvelimen päässä
kannattaa käyttää hankittua sertia, vaikka lets encryptiltä ilmaiseksi. itse payloadin mikä kulkee https tunnelin sisällä voi sitten salata itse allekirjoitetulla (tai päätelaitteen luomalla vaikka keskustelukohtaisella sertillä) sertillä kryptatulla salauksella, jos haluaa vaikka kantaan tallentaa datan siten, että vain kirjoittaja ja kohde jolle data lähetettiin voi purkaa sisällön
Turakointi kirjoitti:
- Jos sertifikaatti ei ole "luotetun tahon" hyväksymä, niin nykyselaimet näyttävät käyttäjälle melkoisen vahvaa kieltä sisältäviä perättömiä väitteitä sisältävän varoitussivun - esimerkiksi Chrome konkreettisesti väittää sivun yrittävän varastaa luottokorttitiedot.
Sertifikaatin voi helposti hankkia ns. luotetulta taholta täysin ilmaiseksi, kuten ketjussa on jo mainittukin.
Turakointi kirjoitti:
- Lähiverkon IP-osoitteelle ei saa sellaista sertifikaattia, jonka selain hyväksyisi. Selain ei edes tiedä, mitkä ip-osoitteet ovat lähiverkon osoitteita.
Selain hyväksyy kaikki sertit, jotka on merkattu "turvallisiksi" käyttöjärjestelmän tasolla. Voit luoda tarvittavat sertit omalla koneellasi ja lisätä ne käyttöjärjestelmän rekisteriin, jolloin niitä kohdellaan kuin mitä tahansa muitakin luotettuja sertifikaatteja.
Tämä on tarkoitettu vain paikalliseksi ja yksityiseksi ratkaisuksi, joten älä jaa itse luomaasi juurisertiä eteenpäin, sillä se altistaa SINUT ulkopuolisille hyökkäyksille.
Turakointi kirjoitti:
- HTTP salataan yksinkertaisesti käyttämällä HTTP-protokollaa TLS-protokollan hyötykuormana. Sertifikaatit assosioidaan yhteen DNS-osoitteiden kanssa, mutta HTTP-palvelin tietää vasta TLS-kättelyn jälkeen, mistä hostnamesta asiakas haluaa hakea sivun (HTTP:n "Host-name"-optio). TLS-protokollassa on SNI (Server Name Indication), mutta siinä DNS-nimi menee salaamattomana, mikä on monessa käyttötapauksessa tietoturvariski.
Mikä tietoturvariski? Liikenteen kulkeminen täysin salaamattomana sisältää kaikki samat riskit ja paljon monia muitakin. Tietosi ovat myös jokseenkin vanhentuneita, sillä selaimet tukevat jo nyt uutta Encrypted Client Hello -standardia, joka korjaa mainitsemasi SNI:n puutteita.
Turakointi kirjoitti:
- Sekä turvallisuuden että itse hostaamisen helpon mahdollistamisen kannalta olisi järkevintä, jos selaimen käyttäjä saisi itse hallita hyväksyttyjä sertifikaatteja ja sertifikaattiauktoriteetteja. Nykyselaimet eivät kuitenkaan sellaista anna tehdä.
...koska ominaisuus ei kuulu selaimille vaan käyttöjärjestelmälle. Voit aivan vapaasti rekisteröidä uusia auktoriteetteja omalla koneellasi, minkä jälkeen kaikki selaimet ja muut softat (esim. palvelinohjelmistot, curl, debuggerit) hyväksyvät omat sertisi.
Turakointi kirjoitti:
Oma projekti on täysin jäissä näiden ongelmien takia. Nyt vielä kaiken lisäksi moni selain alkaa vähitellen estämään kokonaan salaamattoman HTTP:n käyttöä, mikä tekee selaimen kautta tapahtuvasta tekstichattailustakin tuolla omalla systeemillä mahdotonta.
Paikallisen kehitysympäristön konffaaminen HTTPS:lle on itse asiassa aika helppoa, kunhan ensin käyttää vähän aikaa ja käy läpi oppimisen vaivan. Käytännössä lähiverkossa operointi ei aiheuta ylimääräistä vaivaa kuin oman sertifikaatin luomisen verran.
Eikös tuo sertifikaatti kuitenkin vanhene? Eli mikäli asennan oman sertifikaatin asiakkaan kotiverkossa olevalle automaatio-ohjaimelle, niin ajan kanssa tuo sertifikaatti vanhenee ja alkaa tulla ilmoituksia?
No siinä sertifikaatissahan se määritellään, milloin se vanhenee.
En sit tiedä, alkaako selain valittaa jos vanhenemisaika on vaikka 50 vuotta. Onhan tuo tietoturvamielessä epärealistisen pitkä vanhenemisaika, koska luultavasti sertifikaatin allekirjoitusalgoritmi on 50 vuoden päästä helppo murtaa.
jalski kirjoitti:
Eikös tuo sertifikaatti kuitenkin vanhene? Eli mikäli asennan oman sertifikaatin asiakkaan kotiverkossa olevalle automaatio-ohjaimelle, niin ajan kanssa tuo sertifikaatti vanhenee ja alkaa tulla ilmoituksia?
Sertifikaatti pitääkin uusia.
Uusimisen voi myös automatisoida, eli siitä ei halutessaan tarvitse itse huolehtia ollenkaan.
Niin - jos käyttää luotetun tahon sertifikaattia niin se kannattaa tietenkin uusia automaattisesti.
Oma kommenttini pitkästä voimassaolosta liittyi siis siihen jos käyttää ihan omaa sertifikaattia niin että on tehnyt oman luotetun myöntäjän, niin se luotettu myöntäjä tarvitsee asentaa uudelleen sitten kun sen sertifikaatin voimassaolo umpeutuu.
groovyb kirjoitti:
Uusimisen voi myös automatisoida, eli siitä ei halutessaan tarvitse itse huolehtia ollenkaan.
Mutta vaatii domain nimen ja mikäli asennan automaatio-ohjaimen asiakkaalle verkkoon mistä ei ole pääsyä ulkomaailmaan niin sertifikaatti ei pysy itsekseen ajantasalla millään? siksi olen päätynyt käyttämään krypto kirjastoa ja salausavain pohjaista ratkaisua omiin tarpeisiini.
Mikset päivitä sertifikaattia samalla kun toimitat muita ohjelmistopäivityksiä?
Eikä sertifikaatin tarvitse sinällään vanhentua ikinä. Ongelmia alkaa tulla vasta sitten, kun sertifikaatin luomiseen käytetyt kryptografiset algoritmit vanhenevat ja selaimet alkavat hylkiä niitä. Tätä ei kuitenkaan tapahdu kuin harvakseltaan.
SSL sertifikaatin saa ilmaiseksi Latsencrypt sellaisena:
https://letsencrypt.org/
Ja sitten Apache2 VirtualHost-tiedostoon pitää laittaa alla olevat muuttujat:
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
#Jotain muutujia
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLHonorCipherOrder on
SSCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
Header set Referrer-Policy "no-referrer-when-downgrade"
Header always set Public-Key-Pins "pin-sha256='xxxx'; pin-sha256='xxxx'; pin-sha256='xxxx'; max-age=31536000"
Header always set X-Xss-Protection "1; mode=block"
Header always set X-Content-Type-Options "nosniff"
Header set Permissions-Policy: "accelerometer=(), camera=(), geolocation=(), gyroscope=(), magnetometer=(), microphone=(), payment=(), usb=()"
Header always set X-Frame-Options "SAMEORIGIN"
Header set Cache-Control: "no-cache, no-store"
</IfModule>
</VirtualHost>
</IfModule>Ja SSL:n tietoturvaa voi testata täällä: https://www.ssllabs.com/ssltest/
Apachen osalta riittää että konffissa otetaan SSLEngine käyttöön ja viitataan letsencryptin generoimiin sertitiedostoihin
SSLEngine on
SSLCertificateChainFile /etc/letsencrypt/live/{domain}/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/{domain}/privkey.pem
SSLCertificateFile /etc/letsencrypt/live/{domain}/cert.pemjalski kirjoitti:
Mutta vaatii domain nimen..
Jos kyse on asiakkaan ympäristöstä, mikset vaan käytä asiakkaan osoitteistoa ja anna heidän huolehtia salauksesta omien sisäisten domainien osalta? Esim softa.asiakasdomain.fi joka toimii sisäverkossa, jonka osoitteistoa hallitaan asiakkaan bind9:llä tai vastaavalla. Asiakas voi käyttää vaikka omaa julkista sertiään sisäverkon osoitteistossa, vaikka ei se kovin suotavaa olekaan.
Https sisäverkon sisäisessä liikenteessä on monesti myös aika turhaa tunnelointia, koska jos joku haittaa tekevä taho pääsee sisäverkkoon liikennettä tarkkailemaan, ohjelmistosi puuttuva https tunnelointi lienee pienin pahasta varsinkin jos sisällön payload kulkee kryptattuna. Saati jos itse data on asiakkaan omistamaa, eli ei ole ongelma jos asiakas itse tarkkailee kulkevaa sisältöä.
Yleisesti https on tarpeen julkiselle liikenteelle, ei sisäiselle ja siksi saapuvan liikenteen tunnelointi monesti suljetaankin jo web-palvelimen päässä, ja reverse proxytetään salaamattomana sisäverkossa sijaitsevaan palveluun.
Mikäli sisäverkossa puuttuva https silti aiheuttaa ongelmia (esim asiakas ei ole tyytyväinen koska selain ottaa yhteyden ilman salausta ja käyttäjät panikoivat sen vuoksi), kannattaa pohtia desktop sovelluksen tekoa ja käyttää ohjelmistoa ilman selainta, normaalina asennettavana sovelluksena. Ja jos tarpeen, tähän saat lisäksi rakennettua vaikka M2M sertiautentikoinnin, jolloin rajapintaasi ei saa yhteyttä ilman tarvittavaa itseluotua sertiä ja jota oma desktop-ohjelmistosi käyttää rajapintaa kutsuttaessa.
groovyb kirjoitti:
(15.01.2024 23:08:17): Apachen osalta riittää että konffissa otetaan...
Kyllä näin mutta noi muut muuttujat siinä alempana olivat vain SSL-salauksen tietotuvaluokitukseen vaikuttavia juttuja, ettei se tue liian vanhaa TSL:llä, tms. Peruskäytössä näillä tietoturvaluokituksilla nyt niin mitään tee, koska ne tuskin vaikuttaa perusyrityksen myyntiin mitenkään. Eriasia sitten jos myydään pilvipalvelua.
Aihe on jo aika vanha, joten et voi enää vastata siihen.