Blogs

    Publish
     
      • Securing Telecommunications with Encryption

        Oct 20 2017, 8:46 PM

        by Terri Parker 2

        I know you have been waiting for this and it’s finally here!  May 17th is Voice Telecommunication day! One of the most common subjects raised, year after year, is how do we secure our telecommunication channels?

        In the past, where telephone calls were placed over a land line (PSTN), the only security issue was to worry about surveillance by the telephone company, and anyone who physically intercepted the line between you and the person you are talking to.

        While there are hardware devices and actual crypto-phones that can be used to safeguard your conversation, the devices come at a high price and with the move to mobile and internet communication, the effort & costs involved to install can be considered unnecessary.

        The advance in telecommunication networks and the Internet have made communicating easier and more cost effective, but unfortunately have also made the interception of calls more rampant than it has ever been. Without taking extra steps to protect your privacy, every phone call is vulnerable to eavesdroppers.

        If you're using a mobile phone, your conversation is conducted over a broadcast channel, which is easier to intercept than a physical line. There are numerous protocols involved in mobile technology with the most common being GSM.

        One thing that makes GSM special is its call encryption capability: it is designed to encrypt calls in between the handset and the local tower. Your GSM SIM card stores an encryption key, which is authenticated by your service provider (who has a copy of your key), at the nearest tower. The main problem with GSM is that the tower doesn't check back, which means that anyone can create a 'fake' tower and intercept your call.

        The GSM protocol dates back 30 years and the technology behind it, while still useful, is somewhat outdated. Fortunately Smart Phones support improved 3G or LTE standards, offering improved encryption and mutual authentication between your device and tower.

        If you're planning to deploy VoIP (Voice over Internet Protocol), or are already using it within your company, you firstly need to ensure that the data network you are using is secure. VoIP is vulnerable to all of the intrinsic security problems associated with IP and because VoIP transmits digitized voice as a stream of data, there is a risk of theft of private information by a hacker.

        There are many technologies, hardware and software involved in a VoIP system (depending on your requirements), such as

        • IP Phones- the end points that create and receive calls
        • Communication server/router – responsible for provisioning, monitoring & administering
        • Voice/Media Gateways  - contains protocols that interconnect your VoIP system and facilitate calls between IP and analogue

        Ensuring that they are secure is critical to keeping your network safe.

        VoIP uses the Session Initiation Protocol (SIP) and the Real-time Transport Protocol (RTP) for call signaling and voice-message delivery, these protocols do not encrypt the data

        Installing a Symantec SSL certificate on your VoIP server greatly enhances the security by encrypting the signals and securing the voice streams between your devices, preventing MITM (Man in the Middle) attacks and other compromises.

        Secure your communications with a Symantec Premium SSL certificates and implement an additional layer of protection with its free malware and vulnerability scanning services.

        Frequent scans of your server will help protect your networks from unwanted intrusions and help you proactively mitigate vulnerabilities.

        In addition to the Malware and Vulnerability services that Symantec Premium SSL certificates offer, it also includes a free an ECC (Elliptic Curve Cryptography) certificate alternative at no additional cost. ECC certificates provide stronger security and increased server performance due to the shorter key lengths (e.g. 256 bit ECC key provides the same level of security as 3,072 RSA key). It also reduces computational overhead on the server’s resources. Enjoy the flexibility of being able to use a single SSL certificate that can secure multiple domain names by simply adding them onto the same certificate. These types of certificates are known as SAN certificates or Unified Communications (UC) certificates and are commonly used with Microsoft server products (MS Exchange Server, MS Lync server etc.).

        Data Cables.jpg

        • Products
        • website security solutions
        • DigiCert Complete Website Security
        • Products and Solutions
        • Symantec Website Security
      • Vulnerabilities in Mobile Apps

        Mar 30 2018, 4:14 PM

        by Unknown 1

        Recently, we read about lots of SSL/TLS-related vulnerabilities found in mobile apps, which should come as no surprise. We were warned about this back in 2012 (see my previous blog). More warnings came in 2014 from CERT and FireEye. The Open Web Application Security Project (OWASP) listed “insufficient transport layer protection” as number three in its top 10 list of mobile security problems of 2014.

        One recent study found that thousands of mobile apps still used an old version of the OpenSSL library that was vulnerable to the FREAK attack. A similar problem was revealed by the creators of a popular mobile networking library called AFNetworking, when they disclosed a serious bug in their library that bypassed all SSL/TLS security checks. Although this bug and the one in OpenSSL were quickly corrected, thousands of mobile apps remain vulnerable until their developers recompile with the fixed version of AFNetworking or OpenSSL, and users upgrade to the fixed version of each app. Because these bugs were in application libraries and not in the operating system, phone vendors cannot automatically apply a patch. Given the slow rate at which users upgrade mobile apps, these vulnerable apps are likely to be with us for a long time.

        Failure to properly write and test SSL/TLS-related code might be due to ignorance or an assumption that the platform or library will “get it right”.  Sometimes SSL/TLS checks are disabled during development and debugging. App creators intend to re-enable the checks before the app is shipped, but they forget. That’s apparently what happened with Fandango and Credit Karma, who were cited last year by the FTC for SSL/TLS failures in their mobile apps.

        Developers don’t have to use blind faith; some good tools are now available for testing how an app works in the presence of a Man-in-the-Middle (MITM) like CERT’s Tapioca.

        In addition to the SSL/TLS certificate validation tests described in the white paper linked by my earlier blog, developers might also consider Public Key Pinning, defined in a relatively new RFC from the Web Security working group at the Internet Engineering Task Force (IETF). Developers need to apply caution, however, since one study pointed out the difficulty of building it correctly and the consequences of mistakes.

        • Products
        • website security solutions
        • DigiCert SSL TLS Certificates
        • Products and Solutions
        • Symantec Website Security
      • 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