• VIP Push now available with Symantec Identity: Access Manager

        Oct 20 2017, 9:06 PM

        by Teresa Law 2

        Symantec Identity: Access Manager (SAM) now supports VIP Push and will soon support VIP Login.

        VIP Push

        When we introduced VIP Access Push we told you how much more convenient it is – you automatically receive a Push verification to your registered mobile device upon sign-in, replacing the need for you to manually enter a security code – it’s just a push of a button.  We’ve now taken it one step further and made it available as the login method for SAM.   When combined with the SAM Single Sign-On portal you can now login to ALL your applications in a secure yet user friendly manner.

        VIP Push with SAM2_0_0.jpg

        VIP Access Push uses a challenge-response authentication technique and a 2048-bit asymmetric key to securely and uniquely identify the device and help protect against a security breach. You are notified on your device each time there is a login attempt and have the option to deny any request.  In the event that a mobile device is offline, you will have the option to use the six-digit security code from the same VIP Access app to authenticate. The VIP Access Push feature is supported on iOS and Android platforms.

        VIP Login

        As you can see from the SAM login portal we also offer login using Symantec Managed PKI and are getting ready to support VIP Login.  VIP Login replaces the cumbersome password with a  PIN defined by you.  Passwords get reused and can be difficult to remember, while a PIN is much simpler to remember and is generally not reused – think of your ATM card.

        VIP Login with SAM3.jpg

        Find out more about Symantec Identity Access Manager now visit the website.

        Follow us on Twitter: @SymantecSAM, @SymantecVIP,  or @SymantecMPKI

        • 2FA
        • Products
        • symantec vip
        • SAM
        • #SSO
        • Products and Solutions
        • VIP
        • Managed PKI for SSL
      • Gogo Inflight Internet is Intentionally Issuing Fake SSL Certificates

        Oct 20 2017, 8:53 PM

        by Unknown 7

        It was recently disclosed that Gogo, a provider of Wi-Fi Internet services on commercial aircraft, has been issuing spoofed SSL certificates for Google sites that were viewed by customers of Gogo’s service. It appears that Gogo Inflight Internet was acting as an SSL Man-in-the-middle (MITM), a technique used within some enterprises to allow themselves to inspect and control all web traffic, even traffic to secure web sites.  To understand what this means, let me explain MITM in a bit more detail.

        While not very common, there are enterprises that use SSL MITM technology to protect their employees and assets. For example, the enterprise can see when their employees visit sites that attempt to deliver malware to eventually block it. Some enterprises might want to ensure that their employees don’t visit inappropriate web sites using company equipment. The enterprise may also deploy a Data Loss Prevention (DLP) solution to guard against company secrets being divulged on public web sites. These uses are justified since the enterprise has an interest in securing its employees and their assets (laptops, desktops, corporate data, etc.)


        Here’s how an SSL MITM works: a browser user tries to open an SSL connection to a web server. The connection attempt is intercepted by the SSL MITM, which opens its own SSL connection to the intended web server. When that web server returns its SSL certificate, the SSL MITM crafts a copy of the certificate using its own public-private key pair and signed by the SSL MITM’s private root certificate. It returns that copy of the certificate to the browser user, who sees a certificate containing the name of the intended web server. Essentially, two SSL connections are set up: one between the browser user and the SSL MITM, the other between the SSL MITM and the web server. The SSL MITM copies traffic back and forth between the parties so they are generally unaware of the SSL MITM. All SSL traffic is encrypted on the wire, but unencrypted in the SSL MITM. This allows the SSL MITM to see everything and even modify traffic in either direction.

        It’s surprising to see a company use an SSL MITM with its customers. When used within an enterprise, the root certificate used by the SSL MITM can be installed and trusted in employee computers because the enterprise has complete control over those devices.  But this can’t be done with the enterprise’s customers, who control their own devices.  As a result, these customers will receive a warning when they visit a secure site intercepted by an SSL MITM. It’s clear from the screen shot in the articles related to this issue that the user’s browser warned them that the site’s certificate was signed by an untrusted issuer.

        What’s not clear is if Gogo performed a man-in-the-middle interception only for YouTube, or only for Google web properties, or for all web properties secured by SSL. There’s no reason to expect that Gogo intercepted only YouTube traffic. If done for all SSL traffic, it’s likely that a Gogo customer visiting their bank online, for example, would be subject to the same SSL MITM. This would be worrisome, because Gogo would then be able to collect usernames and passwords used on all such sites. Gogo’s CTO said “Gogo takes our customer’s privacy very seriously”, but Gogo’s actions raise a red flag. They could possibly have access to customer data that has nothing to do with Gogo or its services, and Internet users in a post-Snowden era are less willing to trust third parties with their personal information.

        Gogo has a legitimate interest in limiting or blocking video streaming, but the way they’ve done it is far overreaching. Perhaps they hoped that customers would avoid using YouTube when they saw a scary security warning. Sadly, an unintended side effect might be to train users to ignore and to click through those warnings, which is counterproductive to the industry’s push for better end-user practices. Ultimately this would devalue all legitimate SSL certificates, and weaken the Certificate Authority/Browser trust model that Certificate Authorities and browser vendors have built and strengthened over the past 15+ years.

        We urge Gogo to reconsider their actions and deploy bandwidth limiting solutions that do not involve the use of spoofed SSL certificates.

        • Products
        • website security solutions
        • DigiCert SSL TLS Certificates
        • Products and Solutions
        • SSL