Posts Tagged ‘SSL’

A Simple, Yet Cautionary Tale

Friday, December 28th, 2012

While we don’t normally cover web development security basics, or find much to report when poking around in iOS apps, a great example of independent investigative tech journalism related to these topics broke late last week. On Nick Arnott(@noir‘s) blog Neglected Potential, he expands on a previous post involving how data is stored within an app(nice shout-out to a personal fave, PhoneView by Ecamm,) to talk about how it communicates with whatever services it may be hooked up to. Generally speaking, SSL and PKI don’t magically solve all our issues(as comically referred to here: This is 2012 and we’re still stitching together little microcomputers with HTTPS and ssh and calling it revolutionary,) and end users reflexively clicking ‘accept’ on self-signed cert warnings is the front lines of the convenience vs. security battle. No, you shouldn’t send auth in plaintext just ’cause it’s SSL. (Yes, you should be seeding any straggler self-signed certs on the devices in your purview so you don’t need to say ‘just for this ONE sites self-signed cert, please just click Continue’.) The fact that a banking users SSN number was being sent to the app on every communication was… surprising, and corrected immediately after the heightened interest resulting from the aforementioned blog post.

Security via public trust

Security via public trust

After the publicity surrounding the post, however, folks were reassured by getting an immediate audience with the Director of Engineering at Simple, Brian Merritt(@btmerr.) Perhaps the flaw may have been considered too contrived a process for traditional(read: an email to their security team) channels at Simple to respond in a way that satisfied Mr. Arnott before he went ahead and published his post. “If only Jimmy had gone to the police,” the saying goes, “none of this would have happened” – please do note that while responsible disclosure was attempted, the issue is with PKI and not Simple itself, and updates were added to the post when clarifications were worth mentioning to present the facts in an even-handed manner. A key take-away is the fact that there is no live, zero-day exploit going on, just the relative ineffectiveness of PKI being exposed.


Although a process can enable the snooping of traffic, by default proxy’d SSL wouldn’t be allowed to start a session

But even more importantly, the fact that observing the traffic was even possible (thanks to CharlesProxy, also recently mentioned on @tvsutton‘s MacOps blog) highlights the ease with which basic internet security can be thwarted, and how much progress is left to be made. Of the improvements out there, Certificate Pinning is one of those ‘new to me’ concept enhancements regarding PKI, which luckily already has proposals in for review with the IETF. (An interesting contender from about a year ago is expounded on at the site.) There are quite a few variables involved that make intelligent discussion of the topic difficult for amateurs, but the take-away should be that you can inspect these things yourselves, as convoluted as it may be to get to the root cause of security issues. Hopefully we’ll have easier-to-deploy systems that’ll enable us to never ‘give up’ and use autosign again.

Thanks to Mr. Merritt, Michael Lynn and Jeff McCune for reviewing drafts of this post.

Thawte No Longer Offering Free Certificates

Monday, October 12th, 2009

Thawte is no longer offering free accounts for mail. As an interim, they are going to offer a free year (through a partner deal) of VeriSign’s similar service which is then $19 after that initial year.


Wednesday, September 23rd, 2009

Virtual Private Networks, abbreviated “VPN” is technology that that allows users to connect from one place to another securely.  What makes it secure is that the connection between point A and point B is encrypted.  An encrypted tunnel is built between Point A and Point B, and then data is passed through that tunnel.

VPN’s come in many different types (protocols).   Some of the most common include the following:


Often called “dial up VPNs”, it technically extends the functionality of PPP. It was originally started by Microsoft, US Robotics, Ascend Communication, 3Com, and ECI Telematics.  Their first draft of their IETF document for the protocol extension was submitted in June, 1996.  The protocol extension is supported by Linux, Mac and Windows workstations.

Current versions of all three operating systems include the VPN Client application pre-installed in the operating system.  All three operating system server versions can also be setup to allow PPTP connections. A Microsoft Routing and Remote Access Server (RRAS) typically uses Microsoft Point to Point Encryption (MPPE) which is based on RSA RC4 and supports up to 128 bit encryption.


IPSec is short for Internet Protocol Security.  It works on Layer 3, and is often called “Site to Site VPN”.  It is usually used to connect one LAN to another LAN, most times using two hardware VPN units at each side communicating with each other.  It can also be used to connect a workstation to the corporate LAN, typically using proprietary software from the VPN manufacturer/developer (although you can sometimes use the built in software in the operating system – as is the case with Windows). The protocol can function in two modes (Transport and Tunnel) and provides end to end security by authenticating and encrypting the packets between parties.  It can support up to 168bit encryption with 3DES.


SSL VPN is a type of VPN that allows communication to happen over https via web browsers.  The main advantage of SSL VPN is that no additional client software is required besides a web browser.  Since no software needs to be installed on a computer, a user can access the corporate network via VPN from just about any computer (i.e, Public Computer, kiosk, etc.).   The disadvantage is that because it tends to make the applications you would normally use a web type of application, you often lose some of the intended user experience of those converted applications.


L2TP is short for Layer 2 Tunneling Protocol.   It doesn’t do any encryption on it’s own, and is often used in conjunction with IPSec (L2TP/IPsec VPN). The biggest thing to remember about L2TP is that it allows more types of applications to communicate through the VPN connection that otherwise are not supported in a standard IPSec implementation.

In a nutshell, deciding which VPN protocol to implement depends on your budget, the hardware that you have, what will be connecting (workstation/user, or LAN to LAN) and the ease of use.  Please feel free to contact us, and we will be happy to help plan out your VPN infrastructure, or answer any questions that you may have.

Using Outlook Remotely with RPC over HTTPS

Friday, July 6th, 2007

Setting up RPC over HTTPS is different than setting up Entourage over HTTP/S. First, an overview of what HTTPS is. HTTPS is the secure form of HTTP, it stands for HyperText Transfer Protocol Secure. This means that you will need an SSL certificate for connection between Outlook and Exchange. RPC is what Outlook uses to synchronize special information over from Exchange. RPC stands for Remote Procedure Call, and is the special programming routine that allows the application (Outlook) to connect with Exchange via OWA.

Now that we’ve established what RPC over HTTPS is, an outline will follow of how to connect Outlook to Exchange using RPC over HTTPS on Windows 2003 Small Business Server.


Small business server comes with many things already installed and ready for use right out of the box for a company. Two of these things are Exchange and Remote Web Workplace. Remote Web Workplace seems to be an idea made by Microsoft so that an Administrator could remote into their server via HTTP/S, and from there can use many tools in Remote Web Workplace to administer the entire network infrastructure via the Small Business server.

Check List:
1. Are you using Small Business Server 2003?
2. Is Exchange functioning and setup correctly?
3. Do you have an SSL certificate?
4. Are ports 80 and 443 open (and 3389 if you’re doing this remotely)?
5. Do you know the NetBios name of the server (right mouse click My Computer and check the computer name)?
6. Do you have Outlook (preferably 2003)?
7. Are the client workstations that need remote access updated with SP2 for XP?

If you have this, then you’re ready to rock.

Getting it All to Work Together

1. Make Them a Member of Remote Web Workplace

Log in as Administrator to the Small Business server and open up Active Directory Users and Computers. Locate the users you want to have access (or create a security group) and add the group or user to the following group called, “Remote Web Workplace”.

NOTE: You may not see this group as a security group in Active Directory, but if you type in the name and press the “Check” button, it should underline itself. You have now confirmed that this is a valid Security Group.

2. Get The Facts

With the new user you created, login to This is the Remote Web Workplace that you are logging into. You should be greeted with a login. Use the credentials for the user (or pick a user from the security group) that is now a member of “Remote Web Workplace”. You should be able to log in. If you cannot, log in to Remote Web Workplace, log in as Administrator and see if you can log in. If you can log in with the Administrator account, check your settings that you’ve applied to the security group, or user, and ensure that they are indeed members of “Remote Web Workplace”.

Once you have logged in, to the right, there should be a link called “Configure your computer to use Outlook via the Internet”, click on it, and it will outline steps that are pretty darn close to what you should setup in Outlook. It’s basically a help file, but it will give you almost exactly what you will need to use RPC over HTTPS. Just in case, I will also outline the steps here that the link will post.

NOTE: It is important that your users can log in to Remote Web Workplace with the users that need access to RPC over HTTPS. If they cannot log in to here, you will NOT be able to user RPC over HTTPS.

3. Configure or Reconfigure the SSL Certificate

When you log in to Remote Web Workplace via HTTPS, you should be greeted with a pop-up that asks if you want to accept the SSL cert. Check the SSL certificate and MAKE SURE THAT THE WEBSITE NAME OF THE CERT MATCHES THE WEBSITE.

If it does, then log in from each computer that needs RPC over HTTPS and install the certificate from Remote Web Workplace by clicking on View Certificate, and then Install Certificate. You can double-check that the certificate is installed by opening up MMC, go to Certificates, pull up the one for User Certificates, and look for one named with the server or domain name as a Trusted Root. Again, make sure that the cert’s name (not the CA issuer) is called by the MX record name (or predetermined Exchange website name) and NOT THE SERVER NAME. After you install the certificate, close Internet Explorer, and reopen it, and log in to Remote Web Workplace. If you are prompted to accept the certificate again, something is wrong with the certificate, and you will need to create a new one.

If the certificate doesn’t match the Exchange website name or the certificate saved keeps prompting you to accept it, you will need to create a new certificate. You can do this by the following:
1. Download IIS 6.0 Resource Kit Tools, available from:

2. Run the application, and install SelfSSL
3. Click on Start -> All Programs -> IIS 6.0 Resource Kit -> SelfSSl
4. In the Command Prompt type the following:

selfssl /T /N:CN=

NOTE: should be your Exchange website name, ie., (without the less-than and greater-than signs).

5. Type “y” to replace the SSL settings for site 1.
6. Log in to Remote Web Workplace again, and display the certificate. Ensure it is now called what it is supposed to (HINT: Before you view the certificate there should be a green check mark for “Certificate matches website name”). Install the cert, close IE, and retest. You should not longer be prompted to accept the certificate.

NOTE: This is important because if the certificate does not match the Exchange website name the connection will FAIL. You will either get a “server not available error” or other unusual errors.

4. Configure Outlook (a.k.a, It’s all Downhill from Here)

NOTE: This is available in Remote Web Workplace under the link: “Configure your computer to use Outlook via the Internet”

1. Go to Control Panel -> Mail -> Profiles and create a new Profile
2. With the new profile create an e-mail account, make sure to choose Exchange.
a. For the server name put the NetBIOS name, NOT THE WEB NAME.
b. For the user name, put in the username of the user.

NOTE: Do not hit, “Check” it will not work.

c. Click on the “More Settings” button.
d. Click the Connection Tab.
i. Checkmark the box that says “Connect to my Exchange mailbox using HTTP”
ii. Press the Exchange Proxy Settings Button
1. For https:// put in the website name that we’ve been getting the certificate ready for.
2. Put a check mark for “Connect using SSL only”
3. Put a check mark for “Mutually authenticate the session when connecting with SSL”.
4. For “Principal name for proxy server:” put the following:
5. Put a check mark for “On fast networks…” and “On slow networks…”
6. For “Proxy authentication settings” change it to “Basic Authentication”
3. Press OK a bunch of times, Next, and then Finish.
4. Make sure that this profile is set to “Always use this Profile”
5. Save your settings
6. Test your settings, and if you’ve done everything right, you should be prompted for your credentials. After you have been authenticated, you should now start receiving e-mail, and be able to view the calendar and do all of the other Exchange type stuff that the users are used to.