How secure are the apps you use on Smart Phones

In my last post I wrote a very brief how-to on how to Capture Traffic from Smart Devices with Fiddler by making it a network proxy. I did just that and the results for a few app’s have upset me. Mainly because it exposes not only my password and user id, it exposed the content that I upload or download. Not Good!

Above is me logging into an application, later followed by my download of content stored on the device. What was shocking at first is that the log on process is all over HTTP, along with all of the communication between my smartphone and the remote server. A man in the middle would love this.

In the /auth_client URL my password along with my email address (user id) was exposed and could be seen clear as day

And then we have the image I downloaded could be captured by the network peeping Tom.

So thinking about this more… How many of us use the same passwords for various services online. If one is captured the would be ‘smart guy’ hacker could use the information they gathered here: email address (log on info) and password and attempt to use them for other known sites. If you are one to use the same password and user id’s then you would have been compromised along with your data

I am not a app developer but I do read up on the guidelines and its clear that many developers are not taking this into consideration when pumping out their app’s to the market place for us to use.

And while SSL helps, the application needs to also validate the SSL Certificate, as some applications do require SSL to be used however they don’t necessarily care if its theirs or the self signed certificate of a would be hacker.  The true test is to force the application to take a SSL cert that isn’t an authoritative it knows (self signed). If it rejects this then your good to go, otherwise you are taking a big risk in using that application on  networks unknown to you.

More so, if you want security then perhaps you (I included) need to use VPN technology on the smart device to ensure the security, and the integrity of the data we value.

This is just one of a few examples I have found. I hope this sparks you to look for others as I have and perhaps reach out to the developers to make the necessary change to protect us all

Google SSL Certificates going to 2048-bit

Coming Soon! In August 2013, Google will start the process of switching its SSL Certificates over to 2048-bit for its services adding stronger security. This information was made public on Stephen McHenry’s, Director of Information Security at Google Blog.

The completion of this project is set to be completed by the end of the 2013 year.

Quoted on the blog Stephen McHenry writes

Most client software won’t have any problems with either of these changes, but we know that some configurations will require some extra steps to avoid complications. This is more often true of client software embedded in devices such as certain types of phones, printers, set-top boxes, gaming consoles, and cameras.

Stephen McHenry also listed a number of examples of improper validation practices that could lead to the inability of client software to connect to Google using SSL after the upgrade, such as matching any other certificate exactly or hard-coding the expected root certificate.

Change is coming soon! Don’t be left behind.

More detailed information can be found here

Disable Revocation Check on SSTP VPN Sessions

Please use the following steps:

You will need the create the following registry Key (REG_DWORD) under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Sstpsvc\Parameters
Setting the key value of 1, will prevent it from checking.

More detailed info below:

Registry subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Sstpsvc\Parameters
Registry entry: NoCertRevocationCheck
Data type: REG_DWORD

You can use this registry entry to enable or to disable the SSL certificate revocation check that the VPN client performs during the SSL negotiation phase. Certificate revocation check will be performed if the value is set to 0. If the value is set to 1, certificate revocation check will be skipped. Notice that you should set this value to 1 only for debugging. Do not set this value to 1 in your production environment. By default, certificate revocation check is performed.

One or more intermediate certificates in the certificate chain are missing

Error:  One or more intermediate certificates in the certificate chain are missing. This is because Windows does not have enough information to verify this certificate.

When upgrading a Server 2003 IIS 6 web site to 2008 IIS7 the certificate exported from IIS6  you may have issues causing windows to give you the ‘Windows does not have enough information to verify this certificate’ error.

This is because one or more intermediate certificates in the certificate chain are missing. To resolve this issue, make sure that all of intermediate certificates are installed. For more information:  

Resolution:  This involves installing the intermediate certificates into the IIS servers, please view the following:

Download the Intermediate certificates applicable to your product:
Note: You MUST install correct thawte Intermediate CA file on your server for your SSL certificate to work and be fully supported in all web browsers.

Thawte DV SSL
Thawte Primary Root CA 2020

SSL Web Server / SSL Web Server Wildcard:
Thawte SSL CA 
Thawte Primary Root CA 2020

Thawte SGC Intermediates (certificate requested before 10.10.2010)
Thawte SGC CA – G2 and VeriSign Class 3 Public Primary Certification Authority – G5 (certificate requested after 10.10.2010)

Thawte Extended Validation:
Thawte Extended Validation SSL CA
Thawte Primary Root CA 2020


What is the difference between Implicit SSL and Explicit SSL?

FTP over SSL (Explicit)
Explicit security requires that the FTP client issues a specific command to the FTP server after establishing a connection to establish the SSL link. In explicit SSL (or in TLS) the FTP client needs to send an explicit command ( i.e. “AUTH SSL” or “AUTH TLS”) to FTP server to initiate a secure control connection. The default FTP server port is used. This formal method is documented in RFC 2228.
FTP over SSL (Implicit)
Implicit security is a mechanism by which security is automatically turned on as soon as the FTP client makes a connection to an FTP server. In this case, the FTP server defines a specific port for the client (990) to be used for secure connections.