Today Google announced[1] limited HTTPS support for Blogspot.  HTTPS support is critical for banking and other areas where online trust is required.  HTTPS is also important for viewing web site content to ensure it’s authentic and free from tampering.  Without HTTPS support, web site content is easily modified in transit.  Google explains their decision to offer HTTPS support is based on their HTTPS Everywhere strategy.  HTTPS is not enabled by default but can be enabled via configuration by the site Administrator.   Custom domains like are not supported via HTTPS on Blogspot.  Google notes, “blogs with custom domains are not supported in this first version” and implies Blogspot will offer HTTPS support for custom domains sometime in the future.  More than likely Blogspot users will be able to load a custom certificate generated popular Certificate Authority’s in the future.  This small improvement is a really big deal for many bloggers!  +1 Google security team!

[1] HTTPS support coming to Blogspot

* Image: Blogger configuration settings.  New HTTPS Settings option.

Updated on June 21, 2016

On Friday September 18, 2015 both Symantec and Google announced an incident with digital certificates used to secure web sites in browsers.  In Chrome a secure connection is indicated by the green lock next to the URL in the browser.  Symantec noted in it’s official post that a “small number of test certificates were inappropriately issued” for three domains during testing.  No mention of the domain names were provided.  The company explains that the certificates were issued outside of company policy by employees for testing.  When the company learned about the policy violation, the employees were terminated, and the certificates were revoked.

In a separate blog post by Google on the same day, we learn the domains in question were and  There is no mention of the third domain.  We also learn the certificates were Extended Validation(EV) type digital certificates.  EV certificates are special since they convey the highest level of trust in a users web browsing experience.  Google notes that the certificates were, “…recorded in both Google-operated and DigiCert-operated [certificate transparency] logs” on Monday September 14, 2015 at 19:20 GMT.  Symantec maintains, “…certificates and keys were always within our control…”  It’s difficult to know what Symantec means by control.  Clearly Symantec’s information systems did not provide adequate security controls to enforce it’s own corporate policies when issuing EV digital certificates.  Symantec reassures the public this time they will, “…place additional processes and technical controls to eliminate the possibility of human error.”  Symantec provides no details about processes and controls leading to the incident or how their new improvements will address security concerns moving forward.  No dumps of the certificates were provided, no digital fingerprints, etc.  Readers cannot verify or check any revocation information to ensure certificates have been properly black listed.  The article provides no verifiable facts for the public.

Symantec refers to the Google digital certificates as “test” certificates.  Google, calls the same certificates, “pre-certificate was neither requested nor authorized by Google.”  In other words, these are EV digital certificates generated on behalf of Google by Symantec, for domains owned by Google, without Google’s permission and used for unauthorized testing.  Isn’t a certificate that’s not requested or authorized by the subject for a domain owned by the subject also known as a – forged certificate?  So what is the difference between a “test” certificate, a “pre-certificate”, and a forged certificate?  I’m not sure.  Certainly the message to the public is softened.  The best course of action for such a serious breach of confidence is a complete disclosure of the event.  Symantec should provide a narrative, a timeline, and complete set of facts so the public verify all statements made independently.  Unfortunately there is no public evidence to support any statements made by Symantec about how they used Google’s certificates.  Trust but verify is one of the basic tenants of security.  In this case we can only trust Symantec but not verify.

The weakness with digital certificates is that the system is predicated largely based upon trust.  CA’s are free to issue certificates for any domain.  For example, if Google normally works with Thawte (a Symantec brand) for issuing certificates for their domains, Verisign or any other CA, can issue a certificate for Google as well.  Nothing prevents other CA’s with roots within Chrome from issuing a certificate for a Google domain or any other domain.  Google notes they developed a Certificate Transparency(CT) measure to address these concerns.  The CT extensions and log servers are new to me so I need to read up on them.  I don’t see a lot of good tools to dump out CT logs.  I need to investigate CT, CT logs, and related tools further.  Maybe I should consider adding CT support to my DeepViolet pet project.  CT has the potential to spot problems during certificate issuance whereas Chrome Certificate Pinning can spot certificate problems at runtime, both CT and pinning work together.  The good news, in spite of the weaknesses, forged certificates are fairly rare in the public.

Additional Resources
No root for you!  Google slams door on Symantec certs
Fuming Google tears Symantec a new one over rogue SSL certs
Proactive measures in digital certificate security

Image: Open Clipart,

IMG_2593.JPGI have been experimenting with building racing drones and (First Person View)FPV gear.  Today I was at the swap meet of the Livermore Flying Electrons RC club with my brother-in-law.  I found a huge deal.  I bought a 90mm Taft Hobby Viper EDF jet and desktop LiPo charger for really low price.  I’m more into multi-rotors but it was too good of a deal to turn away.

Viper Jet in action (VIDEO).   Note, not me flying.

I was thinking a fixed wing aircraft for FPV would be a cool addition.  Although before I fly this jet I’m going to spend some time on a low-cost trainer.  Flying fixed wings are totally different than flying multi-rotors.  One of the great points about fixed wing is that they stay up in the air a long time compared to multi-rotor.  You can really do some long distance FPV on a fixed wing.  Switch to a ground station for your video feed and upgrade your transmitter to UHF and you ready fly missions out to about 50mi (80km).  My new jet is probably not the best FPV platform but it will get me wherever I want to go fast.

By the way, if anyone has resources on security research related to RC please send my way.  I have been looking at different flight controllers, transmitters, ESC’s, and the all the open source software available.  I could also use any information related to radio transmission protocols for popular transmitters.

LinkedIn-Share-Obfuscated.pngI think it’s great that LinkedIn prompts members using LinkedIn API enabled applications about the type of information requested.  This is the minimum amount of transparency all cloud applications should present to their users but what information is included in a connection?  Sure, “1st and 2nd degree connections”  but what does that mean?  Only a members relationship to another member?  Or the connection relationship along with other profile information?  Asking a LinkedIn member to share profile information for another is like asking my Mom if it’s ok for me to come out and play.  It should be each members choice what they want to share about their profile.  I’m open with my information but some are very private and connect only to their closest colleagues.  An easy area of future improvement is to clean up the connection sharing description to users.  A future suggestion, if the type of information can’t be clearly communicated to members don’t do it.
Another area of improvement in this message dialog is provide members some options about the type of information they are willing to share.  Today the choice is all or nothing.  Members can choose to “Allow access” or not use the application.  Essentially many applications hold you hostage on this screen.  You either hand over all your member data or you don’t get access the application.  My concern is that often applications request much more information than the application requires.  I’m not against software developers asking but the user should have some choices.  If LinkedIn is concerned about their members privacy they should provide a checkbox next to each type of information requested.  This allows members to turn off information they don’t want to share (like personal connections) while sharing other types of information.
numbers-site.pngRadio Numbers Stations are clandestine radio stations operating over shortwave radio by government agencies.  The mysteriousness is due to the cryptic and unintelligible messages transmitted, a stream of numbers, and the lack of information around the intended destination.  Sometimes a man or woman may speak the numbers, sometimes the speech is synthesized, and sometimes there’s data but always the destination and message is unknown.  With the advent of the Internet these stations may seem a throwback to a more primitive era; however, there are distinct benefits to this old technology.  First, shortwave signals carry a great distance.

This makes the transmitters difficult to locate without use of radio signal direction finding(DF) gear.  A more important point is that the intended recipient of the message is untraceable since it can be anyone within the radius of the transmission – usually thousands of square miles/kilometers.  Anonymity in the age of the Internet is next to impossible so numbers stations protecting identities of intelligence agents in the field is important.  And last, the messages are encrypted or rendered otherwise unintelligible.  To listen to some real numbers stations check out the web site.  Also check out The Numbers Station Movie Trailer.  I doubt numbers stations are so action packed in real-life but the movie is entertaining.