tag:blogger.com,1999:blog-6843976375835852604.post4776141786612864904..comments2024-03-28T20:05:56.432+02:00Comments on Havaintoja digimaailmasta: Britannian vakoilu ei yllätäPetteri Järvinenhttp://www.blogger.com/profile/08190899459274223616noreply@blogger.comBlogger45125tag:blogger.com,1999:blog-6843976375835852604.post-31489436698587013692013-07-10T10:54:59.460+03:002013-07-10T10:54:59.460+03:00Aiheen vierestä:
Microsoftin Windowsin tämänpäivä...Aiheen vierestä:<br /><br />Microsoftin Windowsin tämänpäiväisistä turvapäivityksistä kun lukee mitä ne sisältävät, herää kysymys mahtavatko ne kaikki virheet tulla sinne aivan sattumalta. Olisi NSA:lle helppoa pyytää Microsoftia laittamaan kuvan avaamiseen liittyvä uusi haavoittuvuus tai Defenderiin liittyvä admin-oikeudet takaava haavoittuvuus edelliseen päivitykseen, ihan vain jotta NSA pääsee käsiksi haluamiinsa verkkoon kytkettyihin koneisiin. Koska tuo on mahdollista, olisi naiivia kuvitella ettei sitä käytettäisi myös hyväksi.<br /><br />En ihmettelisi jos Snowdenin suuri paljastus liittyisi yritys-/teollisuusvakoilun ohella tarkoituksella NSA:n pyynnöstä suunniteltuihin haavoittuvuuksiin jotka poistetaan ennen tai sitten kun virustorjuntayhtiöt saavat niistä vihiä.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6843976375835852604.post-7860179004176957652013-07-01T01:19:19.446+03:002013-07-01T01:19:19.446+03:00Perusteluna SSL liikenteen avaamiselle on se, että...<i>Perusteluna SSL liikenteen avaamiselle on se, että palomuuri tutkii liikennettä viruksien yms. varalta. Onko tätä mietitty lainsäädännön kannalta (ja täytyykö miettiä)? Työntejöiden pankkikäynnit ja emailit näkyvät nyt palomuurille avattuina.</i><br /><br />Tottahan tätäkin on juristit miettineet. Tässä tulos http://www.finlex.fi/fi/laki/ajantasa/2004/20040516:<br /><i>6 §<br />Viestin ja tunnistamistietojen suojaaminen<br /><br />Tilaaja ja käyttäjä voi suojata viestinsä ja tunnistamistietonsa haluamallaan tavalla käyttäen hyväksi sitä varten tarjolla olevia teknisiä mahdollisuuksia, jollei laissa toisin säädetä. Suojauksen toteuttamisella ei saa häiritä verkkopalvelun ja viestintäpalvelun toteuttamista tai käyttämistä.<br /><br />Sähköisen viestinnän teknisen suojauksen purkavan järjestelmän tai sen osan hallussapito, maahantuonti, valmistaminen ja levittäminen on kielletty, jos järjestelmän tai sen osan ensisijaisena käyttötarkoituksena on teknisen suojauksen oikeudeton purku.<br /><br />Viestintävirasto voi antaa hyväksyttävästä syystä luvan poiketa 2 momentissa tarkoitetusta kiellosta.<br /></i><br /><br />Lakiin liittyvä hallituksen esitys on HE 125/2003 http://www.eduskunta.fi/valtiopaivaasiat/he+125/2003 ja suojauspykälän perustelut löytyvät PDF-version sivuilta 53-55.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6843976375835852604.post-48545418146021663342013-06-30T11:54:22.963+03:002013-06-30T11:54:22.963+03:00Miten menee Lex Nokian suhteen?
Jos firma hankkii...Miten menee Lex Nokian suhteen?<br /><br />Jos firma hankkiin SSL:n avaavan palomuurin ja asentaa oman CA-bitti päällä olevan varmenteensa palomuuriin ja työntekijöidensä koneisiin. Perusteluna SSL liikenteen avaamiselle on se, että palomuuri tutkii liikennettä viruksien yms. varalta. Onko tätä mietitty lainsäädännön kannalta (ja täytyykö miettiä)? Työntejöiden pankkikäynnit ja emailit näkyvät nyt palomuurille avattuina.<br /><br />Joku anonyymeistä huomautti aikaisemmin, että kyseessä on myös tietoturvaongelma, voihan palomuuri sisältältää takaportin tai siinä voi olla bugeja.<br /><br />Vai onko Lex Nokia pätevä vain, jos palomuuri tallettaa liikennettä ja sitä tutkitaan yrityksen toimesta? Onko yrityksille myytäviä liikennettä tallettavia palomuureja ylipäänsä olemassa? Ne alkaisivat jo muistuttaa tiedusteluyritysten myymiä SSL avaajia.<br /><br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6843976375835852604.post-15812810513650075882013-06-29T23:18:30.624+03:002013-06-29T23:18:30.624+03:00@ac sanoi...
Tääll̈́ä on aika monta anonyymia, jot...@ac sanoi...<br /><br />Tääll̈́ä on aika monta anonyymia, joten ne menevät helposti sekaisin :)<br /><br />Pointtini oli tuossa, että kun jokin laite mahdollistaa jonkin toiminteen niin se otetaan helposti käyttöön miettimättä asioita esim. tietosuojan ja yms kannalta. Toki rikoksen pystyy tekemään ihan puhumallakin :)<br /><br />@anonyymi<br />Tuo linkkini Fortinetistä oli kuinka se juurivarmenne on asennettava selaimeen, että se Fortinetin ssl-inspection sadaan toimimaan. Yritin tuolla tuoda esille, että juurivarmenetta ei yleensä saa asennettua ihan niin helposti selaimeensa kuin palvelimen varmennetta, jota tuossa itsekkin olet yrittänyt tuoda esille. Pahoittelen, että en osannut asiaa tuoda esille kun yritän pitää tekstini tiiviinä.<br /><br />Kyllä näitä ssl:n avaavia palomuureja/IPS-laitteita on Suomessa käytössä, mutta onko ominaisuus otettu käyttöön missämäärin niin en tiedä, mutta osa palomuureista joissa on ssl:n avaus on tarkoitettu pk-sektorille, joten laitekantaa on paljon. Tuo on siis nykyisten IPS/UTM-laitteiden vakio-ominaisuus ja kuten yllä sanoin niin asioita ei aina tulla miettineeksi lainsäädännön kannalta.<br /><br />Silläkin on merkitystä mitä liikennettä tarkistetaan ja mikä sen suunta organissatiossa on, joten ei noiden laitteiden käyttö laitontakaan ole kun sillä tarkistetaan esim. yrityksen weppipalvelimelle menevää liikennettä.<br /><br />Veikkaisin, että pankit, valtiohallinto, yksityisetyritykset käyttävät noita jo tänä päivänä Suomessa.<br /><br /><br /><br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6843976375835852604.post-77801481700835270952013-06-29T22:52:40.567+03:002013-06-29T22:52:40.567+03:00Vielä yksi PFS linkki Netcraftin tilannekatsauksee...Vielä yksi PFS linkki Netcraftin tilannekatsaukseen asiasta viime viikolta.<br /><br /><a href="http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html" rel="nofollow">SSL: Intercepted today, decrypted tomorrow</a><br /><br />Tilannetta ei voi kovin kehuttavaksi sanoa.<br /><br />Näyttää siltä, että ohjelmistojen tekijöiden ja valmistajien suuntaan on aihetta luoda painetta korjata asia pikaisesti.acnoreply@blogger.comtag:blogger.com,1999:blog-6843976375835852604.post-88214914801467666482013-06-29T22:46:57.669+03:002013-06-29T22:46:57.669+03:00@Anonyymi
Mahtaako tällaisia SSL:n avaavia palom...@Anonyymi <br /><br /><i>Mahtaako tällaisia SSL:n avaavia palomuureja olla todella käytössä Suomessa?</i><br /><br />En tiedä ja siksi kysyinkin sitä samaa tuolla jo aiemmin yläpuolella. <br /><br />Jos on niin pieni julkisuus asiasta voisi tehdä hyvää sen rakentaneille :)<br />acnoreply@blogger.comtag:blogger.com,1999:blog-6843976375835852604.post-91246556029189024472013-06-29T22:01:35.383+03:002013-06-29T22:01:35.383+03:00SSL-terminoinnista...
Niin, siis nykyään lähes ka...SSL-terminoinnista...<br /><br /><i>Niin, siis nykyään lähes kaikki vähänkin isommat saitit ovat sovelluskytkimien takana ja samat laitteet osaavat sitten purkaa SSL:n välistä pois koska siitä on hyötyä palvelujen tuottamisessa.</i><br /><br />OK. Pakkohan SSL-putki johonkin on päättää, joten palvelinpäässä on tietenkin luonnollista että liikenteen avaus tehdään ennen varsinaista palvelinta. Siinä ei sinänsä ole mitään väärää.<br /><br />Ongelma onkin asiakaspään palomuurit, joiden "paremmat" mallit yrittävät päästä tutkimaan SSL-liikennettä. Jos kyse on sähköpostista (ei ihan pieni reikä päästää palomuuria käsiksi IMAP-postilaatikkoon!), riittää oudon poikkeuksen kertahyväksyntä. <br /><br />Surffailussa asiakas pitää suostutella hyväksymään palomuurin juurivarmenne tai sitten uusi poikkeus aina uusilla https-sivuilla. Edellisen voinee toteuttaa vaikka niin, että palomuuri ei päästä asiakasta suojatuille sivuille lainkaan ellei varmennetta asenna?<br /><br />Mahtaako tällaisia SSL:n avaavia palomuureja olla todella käytössä Suomessa?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6843976375835852604.post-57795090554729122652013-06-29T21:35:25.749+03:002013-06-29T21:35:25.749+03:00PFS:ää HTTPS:n säätö ei ole aivan ongelmatonta, al...PFS:ää HTTPS:n säätö ei ole aivan ongelmatonta, alla olevissa blogeissa niistä enemmän.<br /><br /><a href="https://www.imperialviolet.org/2013/06/27/botchingpfs.html" rel="nofollow">How to botch TLS forward secrecy (27 Jun 2013)</a><br /><br />ja<br /><br /><a href="https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy" rel="nofollow">SSL Labs: Deploying Forward Secrecy</a><br /><br />Jälkimmäisessä SSL Labs blogissa on myös Ivan Ristic'n aiempi kirjoitus Maaliskuulta RC4:n ongelmista.acnoreply@blogger.comtag:blogger.com,1999:blog-6843976375835852604.post-91507002768726853432013-06-29T19:50:38.952+03:002013-06-29T19:50:38.952+03:00@Sami Lehtinen
Hyvä kommentti.
Toinen asia johon...@Sami Lehtinen<br /><br />Hyvä kommentti.<br /><br />Toinen asia johon kannattaisi kiinittää huomiota on oletusarvona käytetyt heikot salaimet ja konfiguroida ne pois serverien päästä ja jos nyt jollain on vielä SSL 3.0 tai TLS 1.0 vanhempia asiakasohjelmistoissa päällä niin ne pois päältä.<br /><br />Kuten jo joku aiemmin mainitsi, niin serverin päässä kannattaa järjestää <a href="http://en.wikipedia.org/wiki/Perfect_forward_secrecy" rel="nofollow">PFS</a>:ää tukevat protokollat, ECEDH tai EDDHE ohjelmistosta riippuen, neuvoteltavaksi ensin jos clientit niitä tukevat.acnoreply@blogger.comtag:blogger.com,1999:blog-6843976375835852604.post-50456161291094330562013-06-29T19:29:37.830+03:002013-06-29T19:29:37.830+03:00Kaikki eivät tule ajatelleeksi, että tietoturvatuo...<i>Kaikki eivät tule ajatelleeksi, että tietoturvatuotteet mahdollistavat melko helposti Suomen lain rikkomisen. Tämä koskee palomuureja, ips, url-filtteröintiä ja virustorjunta -tuotteita.</i><br /><br />Kaikki eivät myöskään varmasti tule ehkä ajatelleeksi, että melkeinpä mitä tahansa esinettä tai laitetta voi käyttää rikkoakseen Suomen Lakeja.<br /><br />Hieman tarkemin kun ajattelet, niin et edes tarvitse mitään laitteita tai esinettä Lakien rikkomiseen ... <br /><br />Joten pointtisi on?<br /><br /><i>Alla linkkiä siihen juurivarmenteen asentamiseen käsipelillä.<br /><br />http://kb.fortinet.com/kb/viewContent.do?externalId=FD32404<br /></i><br /><br />Tuo dokumentti kuvaa aivan standardin prosessin miten Fortigate Managerissa (tuttu ohjelma) olevasta privaatista CA:sta, jonne on luotu oma juurivarmenne, exportataan se ensin työpöydälle ja sitten asennetaan se selaimen kautta Windowsin varmennevarastoon.<br /><br />Vastauksesi osoittaa, että et taida vielä ymmärtää asiasta kovin paljoa, postailet viitaten huimiin ominaisuuksiin valmistajien dokumenteissa. <br /><br />Jotta tämä ei menisi aivan vänkäämiseksi, niin laita toimeksi ja näytä käytännössä että onnistuu. Luo Proof-of-Consept* verkkoon ja postaa sitten nähtäville tänne.<br /><br />*) Esim PoC -näyttö.<br /><br />- Proxy-purkki, jonka takaa / läpi https:llä vieraillessa vaikka googlen tms. saitilla asentuu itse luomasi CA varmenne. <br /><br />- OK, se että selain varottaa ekalla yrityksellä väärästä varmenteesta ja kysyy haluatko tallentaa, siihen vastataan YES hyväksytään.<br /><br />PoC hyväksymiskriteerit: <br /><br />- Edellisen jälkeen kun vierailee jollain toisella saitilla myös https:llä, niin saitti onkin allekirjoitettu luomallasi varmenteella.<br /><br />- Varmenteen on oltava nimen omaan CA-varmenne ja sen on asennuttava Varmentajien varmenteiden joukkoon selaimen tai käyttöjärjestelmän varmennevarastossa ja sillä on oltava riittävät luottoasetukset, jotta se voi toimia juurivarmenteena esim. HTTPS liikenteelle.<br /><br />- Testi on voitavat toistaa jonkun toisen toimesta, siksi sinun tulee dokumentoida tarvittavat laitteet, ohjelmistot tms. mitä käytit sekä tarvittavat toimenpiteet vaihe vaiheelta riittävällä tarkkuudella.<br /><br />Ja nyt ei muuta kuin tekemään, jään odottelemaan näyttöä. Varmasti myös joku muukin osoittaa kiinnostusta kun teet siitä videon Youtubeen.<br /><br />Ei siis mitään: Lataa täältä ensin työpöydälle juurivarmenne ja asenna se ... sellaiseen menevä on täysi hölmö kuin <a href="http://www.virustorjunta.net/modules.php?name=Forums&file=viewtopic&t=39" rel="nofollow">Turkulaiseen Virukseen</a> vitsissä tai jonkun muun Troijalaisen vapaaehtoisesti itse asentava yhtä aivoton hölmö. <br /><br />PoC:n tarkoituksena ei siis ole todistaa, että suuri osa Internetissä surfaavista on naiveja hölmöjä, se ei ole uutinen. Ei ole ollut enää pitkään aikaan. <br /><br />PoC:n tarkoituksena on osoittaa, että vaatimaton vierailu jollain palvelinsivulla, palvelinvarmenteen hyväksyminen, voi samalla aiheuttaa juurivarmenteen asentumisen.<br /><br /><i>ja helppotajuinen esitys tuosta ssl:n tarkistamisesta.</i><br /><br />Heh, varmasti on olemassa asioita, joita en vielä ole hoksannut ssl:stä 15v sitä päivittäin käytettyäni töissä, pidettyäni CA:ta ja toimittuani varmenteiden hankkijana ja RA:na isohkolle työnantajalleni, mutta kyllä minulla hieman enemmän kuin perusasiat on varsin hyvin hallussa jo tässä vaiheessa :)acnoreply@blogger.comtag:blogger.com,1999:blog-6843976375835852604.post-80739363049087172022013-06-29T14:28:29.368+03:002013-06-29T14:28:29.368+03:00Pitkästi on kommentoitu, mutta yksi asia on tyysti...Pitkästi on kommentoitu, mutta yksi asia on tyystiin unohtunut. Palvelimen oma RSA avain on yleensä paljon heikompi kuin 128-256 bittinen symmetrinen avain. On siis paljon järkevämpää murtaa se, kuin yrittää murtaa yksittäisten istuntojen avaimia. Olisi korkea aika siirtä 256-521 bittisiin ECC avaimiin. mm. AES256:n kanssa pitäisi käyttää 15360 bittistä RSA avainta, jotta oltaisiin edes tasoissa. Mieluusti vielä pidempää, koska AES256 avain on sessikohtainen, mutta RSA avain pysyy samana vuoden tai useita palvelimilla.<br /><br />Vanha referenssi: http://www.nsa.gov/business/programs/elliptic_curve.shtml<br />Sami Lehtinenhttp://www.sami-lehtinen.net/noreply@blogger.comtag:blogger.com,1999:blog-6843976375835852604.post-87112994787652765772013-06-29T13:53:09.454+03:002013-06-29T13:53:09.454+03:00@ac sanoi...
Aivan jos palvelu toimii proxynä, ja...@ac sanoi...<br /><br />Aivan jos palvelu toimii proxynä, ja ssl:n terminointia edellytetään niin silloin näin on tehtävä. Epäilemättä monet UTM laitteet sitä tukevat. Osaatko mainita jonkun tahon suomessa joka sitä käyttää?<br /><br />Niin ne terminoivat yhteyden, tarkistavat sisällön ja tekevät uudestaan salauksen ja välittävät sen kohteeseen.<br /><br />En tuohon pysty vastaamaan, mutta ominaisuus on kytkettävissä päälle lähes kaikissa Suomessa myytävissä laitteissa. <br /><br />Osa laitteista esim. Sonicwall on tarkoitettu pikkuyrityksiin, joten kyllä noita ominaisuuksia käytetään. <br /><br />Kaikki eivät tule ajatelleeksi, että tietoturvatuotteet mahdollistavat melko helposti Suomen lain rikkomisen. Tämä koskee palomuureja, ips, url-filtteröintiä ja virustorjunta -tuotteita.<br /><br />Alla linkkiä siihen juurivarmenteen asentamiseen käsipelillä.<br /><br />http://kb.fortinet.com/kb/viewContent.do?externalId=FD32404<br /><br />ja helppotajuinen esitys tuosta ssl:n tarkistamisesta.<br /><br />http://www.sourcefire.com/security-technologies/network-security/ssl-encryption-decryption<br /><br /><br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6843976375835852604.post-42903794163280806042013-06-28T21:55:45.881+03:002013-06-28T21:55:45.881+03:00Niin, siis nykyään lähes kaikki vähänkin isommat s...Niin, siis nykyään lähes kaikki vähänkin isommat saitit ovat sovelluskytkimien takana ja samat laitteet osaavat sitten purkaa SSL:n välistä pois koska siitä on hyötyä palvelujen tuottamisessa.<br /><br />Käytännössä siis käyttäjän yhteys selaimesta on hyvin usein sovelluskytkimeen ja sitten siitä eteenpäin salaamatonta itse palvelimeen. Palvelin toki salaa liikenteen jos se ottaa uudestaan yhteyden eteenpäin ja väliin laitetaan vielä usein toinen palomuuri.<br /><br />Em. on toiminta on aivan normaalia kun tehdään kertakirjautuminen (SSO) mahdolliseksi sovelluksiin. Samalla tekniikalla yrityksen sovelluksia siirretään pilveen, niihin tehdään samalla kertakirjautuminen ym.<br /><br />Sovelluskytkimistä sen verran, että niitä voi olla sitten iso joukko jos on kyse isosta saitista. Ei ole tavatonta, että kyse on 32 sovelluskytkimen active-active klusterista todella isoissa saiteissa, ja näitä voi sitten olla vielä Anycast tekniikalla ripoteltu eri mantereille.acnoreply@blogger.comtag:blogger.com,1999:blog-6843976375835852604.post-7113118726303471232013-06-28T21:41:55.861+03:002013-06-28T21:41:55.861+03:00Mitä tuo ac:n "SSL-terminointi" tarkoitt...<i>Mitä tuo ac:n "SSL-terminointi" tarkoittaa? Onko kyseessä sama asia: SSL avataan matkan varrella - tosin "omien" toimesta?</i><br /><br />Se tarkoittaa juuri sitä miltä se kuulostaa.<br /><br />SSL terminoidaan palomuuriin, kuormantasaimeen, sovelluskytkimeen tms. jonka tarkoituksena on kuvaamassani tapauksessa vapauttaa taustalla oleva palvelin salaamiselta ym. Sovelluskytkimet jotka tekevät em. temppuja osaavat toimia välimuistina, multiplexata satoja yhteyksiä taustapalvelimiin yhdeksi yhteydeksi, uudelleen kirjoittaa headereita, lisätä ja poistaa niitä, uudelleen kirjoittaa URL:n jne. Kaiken tämän tarkoituksena on taata katkeamaton palvelu clientille, nopeuttaa palveluja, mahdollistaa SSO, tasata kuormaa taustalla oleville palvelimille automaattisesti, estää SQL-injektoita, estää henkilötunnuksia, salasanatiedostoja, jne. tietoturvaan liittyviä tietoja vuotamasta ulos mahdollisen sovellushaavoittuvuuden vuoksi, helpottaa taustapalveluiden huoltamista ym. lukemattomia hyödyllisiä asioita palvelun tuottamisessa. Mutta jotta tämä onnistuisi, on purettava SSL ensin edustakoneessa (ts sovelluskytkimessä) ja sitten ohjata luotetussa sisäverkossa (yleensä paljaana) tieto sovelluspalvelimille. Sieltä sitten taas jos lähdetään ulos ei suojatuihin saitteihin salataan uudestaan SSL:llä tms.<br /><br />Em. on ihan normaalia nykyään ja tämäkin blogisivusto on sellaisen virityksen takana, toki tässä ei nyt ole ssl:ää mulla päällä mutta voisi yhtä hyvin ollakin. Sama juttu pankeissa jne. hiemankin isommissa web-saiteissa. Sovelluskytkimet eivät ole vain WEB-liikennettä varten vaan ne osaavat hyvin monenlaisia protokollia ja kiihdyttävät niitä merkittävästi. Yksi tyypillinen on CIFS joka hyötyy siitä varsin paljon. Myös LDAP, RDP, SSL-VPN ym.<br /><br />Merkittävimpiä sovelluskytkimien toimittajia ovat esim F5 (Big-IP) ja Citrix (Netscaler).acnoreply@blogger.comtag:blogger.com,1999:blog-6843976375835852604.post-66484737229718693592013-06-28T21:41:17.700+03:002013-06-28T21:41:17.700+03:00Totta, mutta näppituntuma on sellainen että 99% kä...<i>Totta, mutta näppituntuma on sellainen että 99% käyttäjistä hyväksyy selaimen tarjoamat poikkeukset sen kummemmin ajattelematta.</i><br /><br />Ja tässä on juuri se syy, miksi tavan käyttäjille ei voi antaa oikeutta asentaa ohjelmia itse työkoneisiin.<br /><br /><i>Toteutustavasta varmaan riippuu tarjotaanko asennettavaksi juurivarmennetta (täältä http://fineid.fi/default.aspx?id=332 voi kokeilla kuinka työlästä asentaminen on) vai pitääkö joka SSL-sivulla hyäksyä poikkeus.</i><br /><br />Eti tainnut ymmärtää mitä tarkoitin, aiemmassa viestissäni.<br /><br />Jotta ymmärrät mikäs siinä on vaikeaa, niin tehdään koe.<br /><br />- asenna jonnekin kone & web-palvelu, vuokraa tai lainaa jos ei ole omia koneita.<br />- viritä koneelle https palvelu.<br />- luo itse omat varmenteesi testiä varten, käyttäen vaikka edellä mainittua XCA ohjelmistoa, ei tarvitse ostaa mistään muualta.<br /><br />Hyvä nyt kun olet saanut ekan vaiheen tehtyä, niin kokeile luoda juurivarmenne (CA bitti päällä) ja saada aikaiseksi se, että kun käyttäjä vierailee kyseisessä palvelussa hänelle tarjotaan hyväksyttäväksi _palvelinvarmennetta_ ja samalla ujutat koneeseen juurivarmenteen.<br /><br />Right, nyt sulla on sitten, jos onnistuit, käyttäjän koneella juurivarmenne. Tee toinen sivusto jonnekin jonka varmenteet allekirjoitat kyseisellä varmenteella.<br /><br />Kyse ei siis ole siitä, että a) käyttäjälle tarjotaan juurivarmennetta asennettavaksi ja hän sen onnistuu asentamaan vaan b) käyttäjälle tarjotaan asennettavaksi palvelinvarmennetta ja samalla asentuu juurivarmenne.<br /><br />Väitän, että on vaikeaa ellei mahdotonta. Uskon, että se onnistuu kun näen ja pääsen koneilemaan itse.<br /><br />Laita vaikka postia Petterille tai jonnekin tänne hänen bloginsa kommenttiin, missä voi käydä kokeilemassa. Odotan mielenkiinnolla onnistutko :)<br /><br /><i>Itse olen törmännyt ilmiöön hyvin samantapaisesti kuin tässä IMAPS-yhteydellä: http://bryars.eu/2011/12/stenaline-ssl-mitm-attacks/ IMAPS:n osalta riittää varmaankin poikkeuksen kertahyväksyntä.</i><br /><br />Kyse on siitä, että kertahyväksynnällä hyväksyt _palvelinvarmenteen_ asentamisen, sen jälkeen asiaksohjelmasi luottaa että olet todentanut että olet yhteydessä oikeaan paikkaan.<br /><br />Palvelinvarmennehan ei ole juurivarmenne. Ymmärräthän varmasti eron?<br /><br /><i>UTM-palomuurit omaavat tuon toiminteen ja palomuurikäytössä ne asetavat tuon oman juurivarmenteensa selaimeen, että pystyvät suorittamaan IPS:n SSL/TLS yhteyksille (Kaikki johtavat palomuurivalmistajat) eli internet ei toimi ellet asenna varmennetta.</i><br /><br />Aivan jos palvelu toimii proxynä, ja ssl:n terminointia edellytetään niin silloin näin on tehtävä. Epäilemättä monet UTM laitteet sitä tukevat. Osaatko mainita jonkun tahon suomessa joka sitä käyttää?<br /><br /><i>Ts. kuten ylempänä kirjoitin, SSL:n korkkaavat palomuurit ovat todellinen ongelma ja riskipaikka. Luottamukselliseksi tarkoitettu data on välillä täysin ulkopuolisen softan käsiteltävänä.</i><br /><br />Näin on jos em. mainitulla tavalla tehdään.acnoreply@blogger.comtag:blogger.com,1999:blog-6843976375835852604.post-29156073398156626972013-06-28T21:36:30.718+03:002013-06-28T21:36:30.718+03:00Mitä tuo ac:n "SSL-terminointi" tarkoitt...Mitä tuo ac:n "SSL-terminointi" tarkoittaa? Onko kyseessä sama asia: SSL avataan matkan varrella - tosin "omien" toimesta?<br /><br />Tuolla tarkoitetaan ilmeisesti tässä yhteydessä sitä, että esim. weppipalvelimen edessä on laite johon ssl-yhteys päätetään ja se jatkaa sen jälkeen salaamattomana palvelinryppäälle.<br /><br />Weppipalvelin pystyy n. 5x nopeammin käsittelemään salaamattomia- kuin salattuja -yhteyksiä.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6843976375835852604.post-89520305991701163192013-06-28T21:10:49.599+03:002013-06-28T21:10:49.599+03:00SSL:n ongelma on se, että pitää luottaa kolmanteen...<i>SSL:n ongelma on se, että pitää luottaa kolmanteen tahoon, joka voi olla NSA, Kiinanvaltio, Telia-Sonera jne. juurivarmenteet tuntuvat lisääntyvän koko ajan. Kehenkä myöntäjään sinä luotat?</i><br /><br />Lähtökohtaisesti en tietysti keneenkään muuhun kuin itseeni. Aito luottamus kasvaa sitä tukevien tekojen ja ajan myötä. Sanelemalla sitä ei voi ansaita :)<br /><br />Olet erittäin oikeassa siinä, että varmentamisen suurin ja polttavin ongelma on siinä, että kuka tahansa juurivarmenteen selaimiin saava voi tehdä varmenteita ihan kenelle hyvänsä, se on selkeästi väärä olettamus ja riskin paikka.<br /><br />Em. ongelmaa aiotaan korjata jatkossa, mutta siihen menee vielä tietysti aikaa ennen kuin se saadaan käyttöön.<br /><br />Ja juuri siitä syystä korkeaa turvallisuutta vaadittaessa ensin poistetaan kaikki varmenteet, siis myös juuri-varmenteet. Ja sitten lisätään luotetut ja todennetut juurivarmeteet uudestaan.<br /><br /><i>Selaimissa on vielä se ongelma, että yhtenäistä CRL (revocation list) käytäntöä ei ole. Useimmiten myönnettyä huonoksi todettua voimassa olevaa varmennetta ei saada mitätöityä.</i><br /><br />Totta. Ja esim OCSP joka on yksinkertaisia CRL:iä nopeampi ja parempi tapa todentaa varmenteen voimassaolo on vielä hyvin vajaasti käytetty.acnoreply@blogger.comtag:blogger.com,1999:blog-6843976375835852604.post-56095810904228457262013-06-28T17:15:27.845+03:002013-06-28T17:15:27.845+03:00On olemassa man-in-the-middle koneita, joihin asen...On olemassa man-in-the-middle koneita, joihin asennetaan jonkin Certificate Authorityn juurivarmenteen private key (juridisella pakottamisella saatu). Nämä koneet generoivat tarvittavat certificaatit lennossa. Käyttäjä ei huomaa mitään. Laitteita myydään periaatteessa vain viranomaisille yms., mutta voihan niitä esim myös 'kadota'. Asian paljastivat jo 2011 Wall Street Journal (Surveillance Catalog) ja Wikileaks (Spy Files) - kannattaa lukea laitteiden esitteet, on jaksettava kahlata lutteloa läpi ja etsittävä SSL interception laitteita. Palomuurit, jotka käyttävät organisaation omia certficaatteja ja avaavat niiden avulla SSL liikenteen ovat ikään kuin noiden lievempiä versioita.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6843976375835852604.post-5913275445107372602013-06-28T14:10:23.372+03:002013-06-28T14:10:23.372+03:00Tuossa olet oikeassa sen juurivarmenteen asentamis...<i>Tuossa olet oikeassa sen juurivarmenteen asentamisen kanssa. Se pitää hyväksyä, poislukien keskitetysti ylläpidetyt ympäristöt.</i><br /><br />Totta, mutta näppituntuma on sellainen että 99% käyttäjistä hyväksyy selaimen tarjoamat poikkeukset sen kummemmin ajattelematta. <br /><br />Toteutustavasta varmaan riippuu tarjotaanko asennettavaksi juurivarmennetta (täältä http://fineid.fi/default.aspx?id=332 voi kokeilla kuinka työlästä asentaminen on) vai pitääkö joka SSL-sivulla hyäksyä poikkeus.<br /><br />Itse olen törmännyt ilmiöön hyvin samantapaisesti kuin tässä IMAPS-yhteydellä: http://bryars.eu/2011/12/stenaline-ssl-mitm-attacks/ IMAPS:n osalta riittää varmaankin poikkeuksen kertahyväksyntä. <br /><br /><i>UTM-palomuurit omaavat tuon toiminteen ja palomuurikäytössä ne asetavat tuon oman juurivarmenteensa selaimeen, että pystyvät suorittamaan IPS:n SSL/TLS yhteyksille (Kaikki johtavat palomuurivalmistajat) eli internet ei toimi ellet asenna varmennetta.</i><br /><br />Ts. kuten ylempänä kirjoitin, SSL:n korkkaavat palomuurit ovat todellinen ongelma ja riskipaikka. Luottamukselliseksi tarkoitettu data on välillä täysin ulkopuolisen softan käsiteltävänä.<br /><br />Mitä tuo ac:n "SSL-terminointi" tarkoittaa? Onko kyseessä sama asia: SSL avataan matkan varrella - tosin "omien" toimesta?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6843976375835852604.post-69490333475412014792013-06-28T13:25:41.858+03:002013-06-28T13:25:41.858+03:00@ac sanoi...
Tuossa olet oikeassa sen juurivarmen...@ac sanoi...<br /><br />Tuossa olet oikeassa sen juurivarmenteen asentamisen kanssa. Se pitää hyväksyä, poislukien keskitetysti ylläpidetyt ympäristöt.<br /><br />UTM-palomuurit omaavat tuon toiminteen ja palomuurikäytössä ne asetavat tuon oman juurivarmenteensa selaimeen, että pystyvät suorittamaan IPS:n SSL/TLS yhteyksille (Kaikki johtavat palomuurivalmistajat) eli internet ei toimi ellet asenna varmennetta.<br /><br />Toisaalta IE6:ssa oli bugi, joka mahdollisti juurivarmenteiden lisäämisen etänä. Tuolla reiällä toteutettiin muutama hyökkäys.<br /><br />Nykypäivänä tehdään myös ikäväkyllä jokerivarmenteita eli mikätahansa.domain.com. Tälläisen varmnenteen joutuminen hukkateille on harmillista. Tälläin esim. Iran vakoili Google-hakuja (DigiNotar)<br /><br />Selainvalmistajat Firefox/IE ja muut poistavat säännöllisesti juurivarmenteita selaimistaan. Esim Trustware, joka alkoi myöntämään alijuurivarmenteita.<br /><br /><br />SSL:n ongelma on se, että pitää luottaa kolmanteen tahoon, joka voi olla NSA, Kiinanvaltio, Telia-Sonera jne. juurivarmenteet tuntuvat lisääntyvän koko ajan. Kehenkä myöntäjään sinä luotat?<br /><br />Selaimissa on vielä se ongelma, että yhtenäistä CRL (revocation list) käytäntöä ei ole. Useimmiten myönnettyä huonoksi todettua voimassa olevaa varmennetta ei saada mitätöityä.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6843976375835852604.post-11032600795776182042013-06-28T09:10:03.424+03:002013-06-28T09:10:03.424+03:00@Anonyymi
Potentiaalinen riskipaikka on palomuuri...@Anonyymi<br /><br /><i>Potentiaalinen riskipaikka on palomuurit, jotka korkkaavat SSL-yhteyden juuri MitM-tekniikalla. Näitähän on kai aika yleisesti isommilla organisaatioilla käytössä.<br /><br />...<br /></i><br /><br />Hoh hoijaa, löysääpäs hieman foliota niin kiertää veri paremmin päässä :)<br /><br />SSL:n protokollassa on selkeitä tunnettuja ongelmia, joita yritetään tilkitä kehittämällä sitä, mutta vedit kyllä aika rankasti mutkia suoraksi ja sen vuoksi päädyit aika huimiin uhkiin. <br /><br />Ei SSL nyt ihan sentään aivan niin rikki ole kuin esitit.<br /><br />Voit kokeilla ja todeta itse, että juurivarmennetta ei asenneta tuosta vain vierailemalla jollakin sivustolla ja siitä johtuen kuvaamasi uhka siitä, että palomuuri asentaa sen tuosta vain MitM:llä on mahdotonta ainakin yleisimmillä nykyisillä selaimilla ja ohjelmistoilla nykytiedon mukaan. <br /><br />Opiskelu- ja kokeiluväline varmenteiden kanssa toimimiseen on näppärä työkalu <a href="http://xca.sourceforge.net/" rel="nofollow">XCA</a>, joka on vapaa avointa koodia oleva pieni varmennepalvelu -ohjelmisto. Sillä pyörittää helposti vaikka pienen yrityksen sisäistä varmennepalvelua omiin tarpeisiin.<br /><br />SSL terminointi (ssl-offload) on yleinen ominaisuus kaupallisissa palomuureissa ja sovelluskytkimissä, koska sitä tarvitaan kun palomuuri laitetaan palvelimien eteen tietoturvan, kuormantasauksen, skaalautuvuuden, kertakirjautumisen toteuttamiseksi, ylläpidon helpottamiseksi tai jonkun muun hyvän teknisen syyn vuoksi jota sillä tavoitellaan. Palomuuri toimii silloin ns. reverse-proxynä. <br /><br />Organisaation rajalla ollevissa reunapalomuureissa en kyllä ole kuullut ssl-offloadingia juuri käytettävän, vaikka olen ollut tekemisissä palomuurien kanssa aika kauan.<br /><br />Microsoftilla on tietääkseni tuote, joka mahdollistaa sen, että kun käyttäjän käyttämässä päätelaitteessa joka on AD:ssa on AD:n juurivarmenne ja palomuurina m$ palomuurituote (TMG?) niin se voidaan konfiguroida tekemään MitM.<br /><br />Homma toimii käytännössä niin, että selaimella ulos yritettäessä m$ palomuuri luo lennossa palvelinvarmenteen ja allekirjoittaa sen AD:n omalla juurivarmenteella, joka siis on AD:ssa olevissa työasemissa. Näin siksi, että juurivarmenne ei kelpaa palvelinvarmenteesta.<br /><br />Sen jälkeen m$ palomuuri voi terminoida ssl:n itseensä ja ottaa toisen yhteyden eteenpäin itse käyttäjän tavoittelemaan palveluun.<br /><br />Silloin tietysti voidaan kuunnella liikennettä tuossa välissä palomuurista, mutta kyseisen virityksen voi havaita siitä että kun katsot selaimesta yhteyden aikana kuka on allekirjoittanut palvelun käyttämän ssl-varmenteen niin varmentajana näkyy olevan AD:n varmenne, eikä vaikkapa joku tunnettu varmentaja joka siellä pitäisi olla <a href="http://notary.icsi.berkeley.edu/" rel="nofollow">ICSI SSL Notaryn</a> mukaan tai <a href="https://www.eff.org/observatory" rel="nofollow">EFF SSL Observatoryn</a> mukaan. <br /><br />Jos käytät selaimena Firefoxia ja pääset asentamaan lisäosia, niin voit käyttää apuna myös <a href="http://patrol.psyced.org/" rel="nofollow">Certificate Patrol</a> lisäosaa, niin huomaat paremmin kuin varmenne tai varmentaja vaihtuu. <br /><br />Tuo lisäosa aiheuttaa oletusasetuksilla vääriä ilmoituksia koska moni kuormanjako- ja tasauspalvelu (CDN) käyttää apuna Anycastia (sama IP ja domainnimi eri puolilla internettiä useaan kertaan). <br /><br />Kun näissä palveluissa on sitten eri varmenteita ja varmentajienkin toimesta niin niistä tulee huomautuksia kun liikenne eri ajankohtina ohjautuu eri koneelle ja varmenne vaihtuu siksi. No, Google on alkanut itse käyttää omaa varmennepalveluaan ja yhdenmukaistaa varmenteitaan joten siltä osin ongelma vähenee ajan myötä.acnoreply@blogger.comtag:blogger.com,1999:blog-6843976375835852604.post-54222617488780343652013-06-27T17:39:46.130+03:002013-06-27T17:39:46.130+03:00SSL saadaan avattua väärilä juurivarmenteilla (joi...<i>SSL saadaan avattua väärilä juurivarmenteilla (joihin Järvinen viittaa), mutta se edellyttää man-in-the-middle tekniikan käyttöä eli liikenne avataan ja cryptataan uudestaan. Se tuskin on mahdollista noin suurelle datamäärälle.</i><br /><br />Potentiaalinen riskipaikka on palomuurit, jotka korkkaavat SSL-yhteyden juuri MitM-tekniikalla. Näitähän on kai aika yleisesti isommilla organisaatioilla käytössä.<br /><br />Kun käyttäjä ottaa ensimmäistä kertaa salattua yhteyttä muurin läpi, selain/postiohjelma valittaa tuntemattomasta CA:sta (esim. FortiGATE CA) ja pyytää hyväksymään poikkeuksen. Tämän jälkeen kaikki sujuu automaattisesti ilman, että käyttäjä mistään huomaa SSL-yhteyksiensä olevan murrettuja. Laitoksen omiin koneisiin varmenne lienee asennettu jo valmiiksi. <br /><br />Selain muodostaa SSL-yhteyden palomuurin kanssa ja palomuuri toisen SSL-yhteyden vaikka pankin kanssa, ja palomuurilla on välissä salaamaton data käsissään. Aika herkullinen paikka NSA:lle asentaa pieni aliohjelma?<br /><br />Voidaanko edes olla varmoja, että jokin lukuisista CA:sta ei olisi luovuttanut allekirjoitusavaimiaan ison palomuurivalmistajan käyttöön? Tällöin yhteyden murtamisen voisi huomata vain vertaamalla yhteyden vastapuolen sertifikaattia eri yhteyksillä.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6843976375835852604.post-5982659021860910732013-06-26T22:22:01.090+03:002013-06-26T22:22:01.090+03:00Hyvä tekninen lyhyt artikkeli tuosta nauhoitetun S...Hyvä tekninen lyhyt artikkeli tuosta nauhoitetun SSL yhteyden avaamisen estämisestä Diffie-Hellman vaidon avulla: http://www.theregister.co.uk/2013/06/26/ssl_forward_secrecy/<br /><br />Kannattaa lukea jutun lopussa myös hyvät kommentit tuohon artikkeliin.<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6843976375835852604.post-6660130405130184542013-06-26T10:19:09.262+03:002013-06-26T10:19:09.262+03:00@Petteri
Salauksen, jonka joku yksi taho voi purk...@Petteri<br /><br />Salauksen, jonka joku yksi taho voi purkaa, mutta muut eivät eivätkä aavista että se on purettavissa on valtavasti etua niille jotka kykenevät.<br /><br />Liittoutuneet luovuttivat Saksalta takavarikoidut Enigmat ym. kansainyhteisön maille, mutta 'unohtivat' kertoa että britit pystyvät purkamaan sen salauksen. Kyse ei ollut vahingosta vaan harkitusta teosta.<br /><br />Em. seurauksena UKUSA sopimuksessa olevat osapuolet (UK, US, Kanada, Australia ja Uusi-Seelanti) saivat valtavasti hyödyllistä tietoa brittien kautta aina -60 luvun lopulle asti koska em. maat, joille oli annettu purettavissa olevat salaimet käyttöön. Britit eivät itse asiassa kertoneet asiasta edes jenkeillekään vaan hämäsivät, että heillä on myyriä jotka kertovat heille salauksen purkamisella saadut tiedot.<br /><br />Samalla tavallahan britit hämäsivät Saksalaisia Huffuf asemilla ja ennen kuin syvyyspommittivat Saksalaisten sukelllusveneitä varmistivat, että alueella oli käynyt ja oli nähtävissä tiedustelukone. Näin Saksalaiset ja muut akselivaltojen jäsenet, eivät osanneet epäillä että britit kykenevät lukemaan heidän salattua liikennettään. Kyse oli tarkoin harkitusta harhautuksesta, jota jatkettiin läpi sodan ja vielä sen jälkeenkin.<br /><br />Joten intialaisilla, afrikan maiden johtajilla ym., joista monet halusivat itsenäistyä luottivat salaimilla suojattuun liikenteeseen täysin täysin. Liikenteen kuuntelun ja salauksen purkamisen myötä britit lukivat siksi kuin avointa kirjaa heidän kommunikaatiotaan, paljolti myös ajatuksen juoksuaan samalla varoen liikaa ottamasta etunojaa ettei huijaus paljastuisi.<br /><br />Aivan samalla tavalla jos NSA tai kuka tahansa kykenee purkamaan tai pääsee tavalla tai toisella salaamattomiin taustajärjestelmissä oleviin tietoihin käsiksi, se ilman muuta haluaa että tiedot salataan verkossa koska<br /><br />a) silloin muut valtiolliset toimijat eivät luultavasti pääse tietohin käsiksi ja siitä on heille etua.<br /><br />b) käyttäjien luottamus välineesen aiheuttaa saman kuin tuossa toisen maailmansodan jälkeisessä Enigma episodissa. Salaa kuuntelevat pääsevät paljon syvempiin salaisuuksiin käsiksi kuin jos viestit olisivat salaamatomia ja keskustelijat välttelisivät puhumasta asioista suoraan ja niiden oikeilla nimillä.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6843976375835852604.post-50999302822845527762013-06-26T05:28:10.862+03:002013-06-26T05:28:10.862+03:00Olihan se kiellettyä. -90 luvulla USA lait kielsi ...<i>Olihan se kiellettyä. -90 luvulla USA lait kielsi yli 56 bittisen avaimen</i><br /><br />Vahvat salaukset oli tarkoitettu sotilaskäyttöön, joten niiden maastavientiin tarvittiin lupa. Ranskassa vahva salaus oli kiellettyä siviileiltä myös maan sisällä. Ja NSA kehitti Clipperiä, jossa oli vahva salaus mutta takaportti sen omaan käyttöön : -)<br /><br />Huvittavaltahan nämä kuulostavat tämän päivän nettimaailmassa. Ne osoittavat, miten nopeaa kehitys on ollut. <br /><br />En tarkoittanutkaan laillista kieltämistä vaan yhteistyötä. Kun Google ja FB kerran tekevät yhteistyötä NSA:n kanssa, se olisi voinut kieltää näitä tekemästä https-salauksesta oletusarvoa. Koska näin ei tehty, yhteistyötä ei joko ole tai sitten NSA:lla on keino saada tiedot muutenkin -- joko suoraan palvelimilta tai salaus murtaen.<br /><br />AES:ää tuskin brute-forcella murretaan, mutta sen kryptografit saattavat tuntea jotain uusia analyysimenetelmiä, jolla työmäärää voidaan vähentää. Hieman samalla tavalla kävi aikoinaan DESin kanssa.Petteri Järvinenhttps://www.blogger.com/profile/08190899459274223616noreply@blogger.com