• We deploy strategies to distribute subsets of servers to users aiming to provide each user with a handful of servers they can reach while not revealing the entire network to one user. To achieve this goal, the size of our network -- and in particular the diversity of our network addresses -- isn't simply a function of our traffic load.
• We use protocol obfuscation to bypass DPI blocking.

• We added the obfuscated SSH protocol to mitigate DPI fingerprinting. This fully random-looking protocol is deployed with a unique obfuscation key per Psiphon server.
• We added an optional HTTP prefix to our protocol to mitigate DPI-based whitelisting of HTTP traffic. This simple prefix is sufficient for regex-based DPI (nDPI and l7-filter) to classify Psiphon traffic as HTTP; and was sufficient to defeat an actual adversary at the time we deployed it.
• We added remote server lists to augment the embedded and discovery servers concepts. While discovery happens only when connected to an existing server, remote server lists can be downloaded even when all servers are blocked. Remote server lists are distributed on S3 and accessed via https://s3.amazonaws.com without a distinguishing bucket name in the URL. In this way, it is difficult for an adversary to block our remote server lists without blocking all of S3 or implementing HTTPS traffic analysis.
• Email is now a major client propagation mechanism. We have an auto-responder that returns links and attachments to custom sponsor/channel Psiphon clients depending on the email address users send to.
• We released an Android client in 2012. The first version included an embedded browser based on Android's WebView. In 2012/2013 we added support for whole device tunneling, which tunnels all Android apps through Psiphon. We have an iptables whole device mode (for rooted Android 2.2+ devices); and a whole device mode that uses Android's VpnService with tun2socks (for any Android 4+ device). Additional features added include egress region selection and proxy chaining.
• We have an iOS client now in alpha testing. This app has an embedded browser.
• Our in-app feedback mechanism sends us messages and optional diagnostics from users. This system has helped us debug many platform issues and blocking issues.
• Changes to discovery algorithms: our discovery algorithms evolve as part of an ongoing process of optimizing our network. Major changes include sharing discovery servers across propagation channels; and adding time-of-day as a dimension.
• Optimizations to connection algorithms: our clients now launch connections to many servers at once when connecting, and keep the "best" connection. This assists in load balancing as well as reducing user wait time as individual blocked servers do not stall the connection sequence.
• Client auto-upgrade was enhanced to use incremental download and to use out-of-band download sites (authenticated with digital signatures). These changes made it more likely that a new client can be distributed at a time of blocking.

At Psiphon, we’re committed to open source development. We talked about this in a previous blog post, and you can access our source code here.

We were recently offered the chance to take this openness a step further with a formal security audit of our Windows and Android products, to be carried out by iSEC Partners. As part of our effort to be transparent in the way we operate, we are pleased to publish this report in full, which you can access here.

Overall, we are very happy with the results of the security audit, and for it to be recognized that we are “actively invested in ensuring the security of [our] users”. We have already addressed the one High Severity item uncovered by iSEC Partners, and will continue to address the other recommendations over time.

The main findings of the report are:

• Psiphon follows most industry best-practices and takes measures to mitigate against attacks where it cannot.
• Most findings were suggestions to further improve the system, particularly in relation to the growth in the number of people using the software.
• No inherent architecture flaws were discovered.
• One High Severity issue was found, related to automated server patching. We have now deployed automated server patching using Ansible.
• Longer-term recommendations are being considered, and where appropriate built in to our development plans.

One particular finding of interest is the recognition by iSEC Partners that there is a potential for security issues related to the browser that we use for browser-only mode. We wrote about that recently when a new security flaw in the browser was discovered, and have already taken steps to mitigate against it.

We were very pleased to be given the opportunity to engage with this security review. We hope that you will find this report interesting, and that it will reassure you of our commitment to providing first-class software that will always be open source and secure.

Summary of Heartbleed impact on Psiphon:

• Some Psiphon servers were using affected versions of OpenSSL, leaving the Python web server vulnerable to the Heartbleed attack. Data at risk, within the web server component process, included Psiphon network topology information and network usage statistics in addition to web server key material.
• The SSH/SSH+ Psiphon tunnels were not at risk. User traffic flowing through the Psiphon servers was not at risk. VPN Psiphon tunnels were potentially at risk for man-in-the-middle attacks as the per-session authentication secret is in Python web server memory.
• On April 8, 2014, OpenSSL patches were applied to all affected Psiphon servers. In addition, all affected servers had their non-SSH/SSH+ capabilities revoked (out-of-band updates to all clients), ensuring clients will not attempt to use potentially compromised web server key material outside of the secure tunnel.
• The Windows client does not use OpenSSL and is not affected by the Heartbleed attack.
• The Android client does not use OpenSSL for its tunnel, but does use Android Java SSL for its web requests to Psiphon web servers and Amazon S3. As Android version 4.1.1 is affected by Heartbleed, our app on this particular version of Android remains vulnerable to Amazon, Psiphon servers, or a man-in-the-middle peeking at app memory.
• The email auto-responder server had the affected version of OpenSSL. The attack against it would be to get it to make a SSL connection to a remote mail server (by sending an email request from an address that uses that server), which could then peek into the memory of the mail server. This could potentially expose email content, including addresses. The OpenSSL patches were applied April 8, 2014.
• The feedback processing server had the affected version of OpenSSL. It may have used that library (via Python + Boto to make SSL connections to Amazon AWS services and Google Gmail server. This means that Amazon or Google could have accessed user feedback data. However, it should be noted that this data is already hosted in Amazon EC2 and a subset of this data is emailed to us via Gmail. The OpenSSL patches were applied April 8, 2014.
• Psiphon was not using an affected version of OpenSSL.