In this edition…
- About This Newsletter
- On the Blog => Learning the Yii Framework
- On the Web => Adobe’s BrowserLab
- On the Web => Zend Interviews
- Q&A => What do I need to know about SSL?
- Book Giveaway => PHP for the Web: Visual QuickStart Guide and Translations
- Larry Ullman’s Book News => Effortless Flex Development
About this Newsletter
Well, I didn’t get many replies to my previous newsletter, so either you’ve all stopped reading or the topics there just weren’t that interesting. I’ll try to do better here, although I’m trying to keep it short (as I always say, but this time I came closer). I suspect the book giveaway will merit some responses! As always, thanks for reading and please do let me know what comments and questions you have.
On the Blog => Learning the Yii Framework
I’ve recently wrapped up three Web sites that used the Yii framework (for PHP). I have not historically been much of a framework person, but after working with the Zend Framework for a while, I found and fell for Yii. I wrote a series of posts on how to start using Yii on my blog. The creator of Yii himself has read the series and found it useful enough to add a link to it to the Yii documentation pages. If you’re curious about using Yii, or just want to see some highlights of what it’s like to work with, head to my blog (and there’s also a series on MVC there, which is useful when working with frameworks).
On the Web => Adobe’s BrowserLab
In case you haven’t caught this yet, Adobe has created a resource called BrowserLab. First, there’s a Web-based version, which only requires a free Adobe account to log in and use. After you’ve done that, enter a URL and you can view how that Web page looks in various browsers. Right now, only browsers on Windows XP (Firefox 2, 3, and 3.5; IE 6, 7, and 8; Chrome 3) and Mac OS X (Safari 3 and 4; Firefox 2, 3, and 3.5) are supported, but it’s a wonderful start. For anyone needing to see how their site renders on other browsers, including operating systems they may not have, this is a wonderful tool. There’s also a way to compare how a page renders on multiple browsers at one time, so that you can get that pixel perfect look. If you’re using Dreamweaver CS4, there’s also a BrowserLab extension, so you can have the same functionality without leaving your Web development tool. For more information and an actual demonstration, see this video on Adobe TV.
On the Web => Zend Interviews
Some time ago I found a series of interviews with various members of the PHP community posted on Zend’s site. They’re pretty interesting for seeing what other people are doing with, or thinking about, PHP. In particular I’d recommend reading the interviews with: Andrei Zmievski, Ed Finkler, and Theo Schlossnagle.
Q&A => What do I need to know about SSL?
Quite a while back I was asked about the various types of certificates being offered for SSL purposes. Many domain registrars like GoDaddy offer levels of SSL certificates, which is a bit strange, frankly. How can a transaction that’s intended to be simply secure be more or less secure? And do you need $30 of SSL security or $100 or $1000? Here’s what I know, starting at the beginning…
So, there’s SSL (Secure Sockets Layer) and the newer TLS (Transport Layer Security), both of which are protocols for providing secure network communications. However, TLS isn’t consistently supported by all browsers so I’ll just talk about SSL from here on out. By using SSL, the data being transferred over a connection is safe from prying eyes and various forms of attack. SSL can be used for securing many things, from FTP to SMTP (for sending emails) to, of course, HTTP, resulting in HTTPS. Most of the security of an SSL connection comes from using a certificate. The certificate is associated with a server or a domain and is passed to the browser as part of the request. The information in the certificate dictates the security level of the transaction. Stepping sideways for a minute…
There are a lot of considerations in e-commerce (as my forthcoming book will discuss!) and many of them relate to security. But security is not a binary state that can be turned on and off, nor is it a matter of just proper programming. Security involves both the application of appropriate techniques as well as the appearance of security. The former will stop the hackers and prevent very bad things from happening; the latter will make your end users comfortable enough to give you their money. This is relevant to certificates because they can be both actually more or less secure and apparantly more or less secure. I’ll explain…
Certficates are computer files that have to be generated. You can buy them from a company for anywhere from $15 to $1500 or you can generate them yourself. These are called “self-signed”. In practice, self-signed certificates can be just as secure as the expensive purchased ones when it comes to protecting a transaction. For example, if I’m creating an admin or special area on a Web site that only I and a couple of others might access, I’ll create my own “self-signed” certificate and use that. The data being transmitted over that connection will be fine (assuming I created the certificate properly), but when any user goes through an HTTPS connection that has a self-signed certificate, they’ll be notified by the browser that the site is using a self-signed certificate and perhaps should not be trusted. This is fine when it’s just me using the connection, or someone authorized to access that area, but it’s not acceptable for the general public. With a self-signed certificate, the certificate itself may be valid, but an untrusted source (i.e., me) is saying that it’s valid, so how can the end user trust that validation? This is where we get back into the appearance of security…
Built into browsers are a list of 50+ major certificate authorities to be trusted. These are companies like Thawte and VeriSign and GoDaddy and others. If you purchase a certificate from a major company, you’re buying, in part, the assurance that the user’s browser isn’t going to warn them about the validity of the certificate. That’s a legitimate reason to purchase a certificate instead of generating your own. Each of these companies also sell levels of certificates and different prices, which is the next consideration.
In terms of actual security (not perceived), one thing that may cost more is the maximum level of encryption used, from 40-bit to 256-bit. The higher the encryption, the better (although the maximum actual encryption level that will be used will depend upon the Web server and the browser involved in the transaction). Next, some certificates come with warranties to re-emburse you in case of a failure. The cheapest GoDaddy certificates might insure you for up to $2,000; expensive VeriSign ones cover up to $250,000. That’s a big difference. (How much does your self-signed certificate cover? Nada.) You’ll also pay more to have a more flexible certificate. A valid certificate for a single domain is cheaper than one for all subdomains (www.example.com, shop.example.com, and admin.example.com); a single certificate valid for multiple domains (example.com and example.net) costs even more. Another consideration is the ability to use the same certificate on multiple servers or not. Only very active sites require multiple servers but, if you do, you’ll need to buy the more expensive certificate.
In terms of perceived security, what you want to buy is a certificate from an authority that’s recognized by all browsers, so no user is ever getting the “we don’t know who this is” message. More expensive certificates also mean that the issuer has done more extensive checks into who the purchaser is. A cheap certificate basically says someone bought this certificate. An expensive certificate says someone bought this certificate for this domain that we’ve validated they own and we’ve confirmed they’re a valid company operating in X country and we’ve spoken to them on the phone and read a letter from their accountant, etc., etc. (and I’m not making all that up). The greater depth of validated information will be reflected in the certificate, not in terms of the actual details, but in “how verified” you are. Finally, you can buy high-end certificates that enable the “green address bar” effect in some Web browsers (also called “extended validation” or EV). This is an obvious, visual cue to the user that they’ve got a really secure connection and it’s safe for them to do whatever they’re about to do. I don’t know how many people are aware of the green address bar as of yet, as I don’t know how many average users even pay attention to broken locks that appear in the Web browser, but if you strive for the highest appearance of security, EV is the way to go.
Oh, and if you spend more money on a certificate, you’ll also get better technical support, yadda, yadda, yadda.
So that’s the gist of SSL certficates and what you’re buying: actual security and perceived security. Both are crucial. But as with all things when it comes to security, you have to find (and pay for) the right amount of security for your situation. Banks obviously cannot overdo it when it comes to security whereas many other sites easily can (although, with security, always err on the side of overdoing it).
Finally, three remaining thoughts…
1. A month or so back I started using Mint.com for monitoring my personal finances. There’s an interesting security model there because I provided them, one time, with my Web login information for my banks, credit cards, mortgages, investments, and more. That may seem crazy, but I’m not worried about it at all. Why? Because Mint uses that information to retrieve the current state of affairs (balances, transactions, and so forth) but I can’t actually move any money anywhere through Mint. So even if I sent my Mint.com login information out in this newsletter, I wouldn’t be at risk of losing any money. Once I’ve set up my Mint.com account, all the remaining transactions could actually go over HTTP because it’s just like getting your bank statements in your snailmailbox or your email (they still use HTTPS, of course; in fact, Mint.com has EV-level certification). The real security Mint.com needs to have is HTTPS when taking the initial login information, and ultimate security in protecting the stored account information on their servers.
2. I should also add that SSL should be used anytime data is being transmitted that cannot be seen by others. This includes e-commerce, but perhaps also login credentials or some form submissions. And in those cases where form data is submitted, you should display AND handle the form using an SSL connection.
3. Certificates aren’t just for securing network transactions. For example, Adobe AIR applications that you distribute need to be signed with a certificate or else they’ll have limited powers when a user goes to install them (this is part of the Adobe AIR security model).
Book Giveaway => PHP for the Web: Visual QuickStart Guide and Translations
You must be subscribed to the newsletter in order to participate in the book giveaways.
Larry Ullman’s Book News => Effortless Flex Development
Right now I’m starting to turn my full attention towards my forthcoming Flex book, tenatively titled Effortless Flex Development. I’m currently working on the table of contents and going through my mountain of notes. The book will be out in the Spring of 2010, focusing on Flex 4, which is currently in beta form. For the server-side of things, I’ll be using PHP, because it’s still my favorite Web development language and because PHP integration is a key feature of Flex 4. As Flex is a framework designed to make Flash development quick and easy, I’m going to weigh the book heavily towards practical applications of the technology, especially with a server component tie-in, and not spend too much time in the minutuae (i.e., I won’t be going element by element with full explanations of each, which can be picked up easily enough in any Flex reference).
