Blogs

    Publish
     
      • Could The Empire Have Been Saved by Better Encryption?

        Mar 29 2018, 10:20 PM

        by Jeff Barto 1

        I jumped at the opportunity to write this blog – as my son’s name is Luke and therefore, “Luke, I am your father”.

        Let’s remember that tense moment in Garbage Compactor 3263827:  after narrowly escaping Death-By-Dianoga, imminent demise again confronts Leia, Luke, Chewbacca and Han as the garbage compactor starts doing what garbage compactors do best.  The young rebels frantically call C3PO and R2D2 to shut down all the compactors on the detention level – and in those gripping minutes leading to their narrow escape, even the most hyperaware geeks all totally missed evidence that the Imperial IT/IS department made some pretty bad decisions about SSL certificates. 

        Garbage.jpg

        For two decades, SSL has been the guardian of encryption and validation on a very public internet, but also within enterprises – even evil enterprises like the Death Star.  And while the chronology means that SSL couldn’t have been in use a long time ago, in a galaxy far, far away, luckily the timing is fiction while SSL best practice is fact. 

        This little lesson’s worth the effort.  Come, let me get you some SSL context: 

        To save his colleagues in the compactor, R2D2 got access to a Death Star control system.  The Death Star’s systems believed that R2D2 was a legitimate agent of the Empire, and allowed him access.  Now, let’s presume that the data exchange which ensued between system access and compactor shutdown was over an encrypted channel (a classic implementation of encryption of data in motion in a server-to-server model).  Encryption wouldn’t have prevented R2D2 from doing anything – since he already had access to the network.

        Had the Death Star’s systems required a digital certificate – what we now call SSL or TLS – for validation, not just encryption, the result might have been very different for not just our rebel friends, but ultimately for the Rebel Alliance and the Empire too – and for millions of Star Wars fans, in any galaxy for that matter. 

        After all, losing track of Death Star plans isn’t Imperial IT’s only problem.  They also failed to observe best practices for usage of specific certificate types within their space station, as encryption couldn’t have prevented R2D2’s access.  Only the validation function of SSL could have resolved that. 

        Stick with me here.  Use the Force.  Trust your feelings.  Let go.

        Effectively, R2D2 was a man-in-the-middle.  Er, droid-in-the-middle.  But don’t let “MITM or DITM” distract.  If the Death Star’s server-to-server authentication demanded domain-validated certificates, the clever R2D2 could have easily obtained one of those since he literally was a man-in-the-middle.  (Think about all the various DV authentication methods – R2 could’ve faked any of them).  And upon system access, R2 just presented his DV certificate upon connecting the Death Star network and – ta da, he’s avoided any Imperial entanglements.  (As I’m writing this, I realize that the Empire would likely have obtained the very first ever TLD, presumably for .ge for galactic empire – making R2’s DV cert’s Common Name to be something like r2d2.deathstar.ge)

        Now, if Death Star IT/IS had configured its systems to demand organization-validated (OV) or Extended Validation (EV) certificates for server-to-server communication, R2 would have either failed to connect (by having a DV cert) or failed OV/EV verification (since he couldn’t have proven that he’s a member of the Empire). 

        No OV/EV = no (suitable) cert presented = this isn’t the droid you’re looking for = dead rebels.

        Moreover, Imperial IT/IS would’ve been even smarter if they’d have selected any of Symantec-branded SSL certificates, which only come in OV and EV flavors – as the Symantec SSL validation and issuance infrastructures have never been compromised – since clearly the Death Star has its own breach problems.

        Moral of the story:   demand Symantec OV or EV certificates, even for server-to-server usage.  And may the Force be with you.

        • Products
        • website security solutions
        • DigiCert Complete Website Security
        • DigiCert SSL TLS Certificates
        • Products and Solutions
        • Symantec Website Security
      • Mitä kuluttajan tulisi tietää SSL-varmenteista

        Mar 29 2018, 8:40 PM

        by Jeff Barto 0

        eBusiness Green Bar 400x210.jpg

        1994 tehtiin ensimmäinen verkko-ostos: iso pepperonipizza herkkusienillä ja extrajuustolla, Pizza Hutista. Seuraavien 20 vuoden aikana verkkokauppatalous on ollut vilkasta ja 2013 myynti ylitti 1,2 biljoonaa Yhdysvaltain dollaria.

        Verkkokaupankäynnin kasvu perustuu luottamukseen. Kuluttajat luottavat sivustojen pitävän kirjaa rahavirrasta, ja että ostosten tekeminen on turvallista ja laillista suurimmaksi osaksi Secure Socket Layer (SSL) –varmenteiden ansiosta, joka tunnetaan myös pienenä vihreänä lukkona osoitekentässä.

        SSL-varmenteet varmistavat, että toimittaja on se, kenen he väittävät olevansa. Se osoittaa myös, että yhteys kuluttajan laitteiden ja yrityksen verkkosivujen välillä on turvallinen. SSL-varmenteiden toiminnallisuuden ymmärtäminen on tärkeää välttääkseen huijarien ansaan joutumisen. Sillä loppupeleissä kaikki sivustot – tai SSL-varmenteet – eivät ole luotu tasavertaisiksi.

        Erilaiset varmennetyypit

        Verkkosivustojen omistajat ostavat SSL-varmenteet varmentajalta (Certification Authority, CA). On olemassa kolmen tyyppisiä SSL-varmenteita, joista jokainen tarjoaa eri tasoisen suojan. Ongelma piilee siinä, että vaikka kaikki varmenteet tarjoavat selaimen osoitekenttään tutun turvalukon yhdessä HTTPS-yhteyden (”S” viittaa englannin turvattu-sanaan, ”secure”) kanssa, turvatasot vaihtelevat suurestikin. Tämän vuoksi on tärkeää ymmärtää millaista SSL-varmennetta sivusto käyttää ennen, rahallisen liiketoimen harjoittamista tai ylipäätään mitään, johon liittyy henkilökotaiset käyttäjätiedot.

        • Domain validated eli domainvarmennettu (DV):  Tämä vahvistaa sivuston omistajan. Prosessi on yksinkertainen, jossa varmentaja eli CA toimittaa sähköpostin siihen sähköpostiosoitteeseen, jolla sivusto on rekisteröity identiteetin vahvistaakseen. Yrityksestä itsestään ei vaadita tietoja. Verkkorikolliset käyttävät yleensä DV-varmenteita, koska ne on helppo hankkia ja sen avulla sivustosta saa turvallisemman kuvitelman kuin onkaan.  Huijarit saattavat käyttää DV-varmenteita houkutelleksaan kuluttajia tietojenkalastelusivustoille, jotka näyttävät aidoilta tai kopioidakseen jonkun sivuston näyttämään tunnetulta sivustolta, mutta jonka tarkoitus on varastaa henkilökohtaisia tietoja.
        • Organizationally validated eli yritysvarmennettu (OV): Saadakseen OV-varmenteen varmentajan on varmennettava tiettyjä tietoja, kuten yrityksen olemassaolon yritysrekisteristä, sen fyysisen sijainnin ja verkkosivuston omistajan. Prosessi kestää yleensä muutaman päivän.
        • Extended validation (EV): Tällä varmenteella on korkein suojaustaso ja se on helpoiten havaittavissa. Myöntääkseen EV-varmenteen varmentaja suorittaa hakijasta tehostetun tarkistusprosessin kasvattaakseen yrityksen luottamusta. Tarkistusprosessissa käydään läpi yrityksen asiakirjat, varmennetta hakevan henkilön identiteetin tarkistus ja tietojen tarkistus kolmannen osapuolen tietokannasta. Turvalukon ja HTTPS:n lisäksi EV-varmenteella suojattu sivusto muuttaa osoitekentässä olevan yrityksen nimen vihreäksi.

        Huomaatko eron?

        norton-communiy.png

        Viimeisin osoite on selvästi suojattu EV-varmenteella. Ensimmäinen on DV-varmenne ja keskimmäinen OV-varmenne, jotka näyttävät verrattaessa identtisiltä.

        Mitä voi tehdä pysyäkseen turvassa?

        Nyt kun tiedetään mikä SSL-varmenne on ja sen kolme eri tyyppiä, ja että DV-varmenteella suojattu sivusto on huijatuksi tulemisen riskialueella, kuinka käyttäjät voivat pienentää riskiä shoppaillessaan ja naputellessaan muuta kriittistä tietoa verkossa?

        1. Ole varuillasi! Vaikka sivustolla olisi turvalukko tai osoiterivin alussa “https” ei tee sivustoa turvalliseksi rahaliikenteelle. Käyttäjät ovat oppineet etsimään näitä kahta ennen tapahtuman läpiviemistä ja juuri tästä syystä verkkorikolliset näkevät vaivan hankkia SSL-varmenteen – näyttääkseen aidolta sivustolta.
        2. Opettele erottamaan, mitä varmennetyyppiä sivusto käyttää. Etsi ensimmäiseksi visuaalisia vihjeitä, kuten lukkosymbolia ja osoitekentän vihreää väriä. Ainoastaan EV-varmennetut sivustot ilmoittavat yrityksen nimen osoitekentässä. Selaimet eivät osaa erottaa DV-varmennetta OV-varmenteesta. Norton on luonut ilmaisen työkalun (https://safeweb.norton.com/) varmenteiden erottamiseksi. Kopioi verkkosivun osoite suoraan työkalun kenttään ja se kertoo, mitä varmennetyyppiä sivusto käyttää ja kuinka turvallinen sivusto on kyseessä.
        3. Asioi ainoastaan OV- ja EV-varmenteilla suojatuilla sivustoilla. DV-varmenteille on aikansa ja paikkansa, mutta niitä ei tulisi käyttää kaupallisilla sivustoilla. Jos käyt testaamassa osoitteen Nortonin työkalulla ((https://safeweb.norton.com/) ja tuloksena on DV-varmenne, mieti kahdesti ennen kuin asioit pidemmälle kyseisellä sivulla. Jos kyseessä on OV- tai EV-varmennettu sivusto tiedät, että yrityksen tiedot ovat tarkistettu.

        Verkkoshoppailu ei ole katoamassa mihinkään. Niin kauan kun ala ei vaadi OV- ja EV-varmenteiden käyttöä kuluttajien on kannettava kortensa kekoon riskien minimoimiseksi verkossa.  Kun riskit on tiedossa, kuluttajat jäävät mitä pienemmällä todennäköisyydellä tietojenkalastelijoiden ansaan.

        Lisätietoja SSL-varmenteista löytyy hiljattain julkaistusta Symantec whitepaperista (https://www.symantec-wss.com/us/ecommerce-security#.VSfVctW3dYZ) tai vierailemalla Trust Services (https://www.symantec.com/ssl-certificates/) –sivustollamme.

        Alkuperäinen teksti: https://community.norton.com/en/blogs/norton-protection-blog/ssl-certificates-what-consumers-need-know

        • Products
        • website security solutions
        • DigiCert SSL TLS Certificates
        • Products and Solutions
        • Symantec Website Security