Fog Creek Software
Discussion Board




usability of SSL web apps?

Hi,

Any advice from the field on this one?  I just installed an SSL certificate on one of my servers.  Several customers require SSL encryption when viewing their data.

The servers host a variety of applications.  Should I enable the SSL on (1) only the ones with highly confidential data (2) the user / login screens of all apps (3) all of the screens of all apps?  I'm trying to figure out the pros and cons.

The other option is to give the user a choice.  Yahoo Mail does this with a discreet "standard" and "secure" hyperlink above the login button.  But why would you choose non-secure? 

WILL

Will Glass-Husain
Thursday, May 15, 2003

> But why would you choose non-secure?

Because non-secure is the default choice, and I am a stupid user and I don't know any better.

--
ee

eclectic_echidna
Thursday, May 15, 2003

Some people are behind a firewall that blocks the SSL port.

Philo

Philo
Thursday, May 15, 2003

I'd pick one or the other and go with it for everything.

pb
Thursday, May 15, 2003

SSL pages typically load slower and put more stress on your webserver (and the client).

Wayne Venables
Thursday, May 15, 2003

Our CGI applications, when tested over dial-up, ADSL and Cable connections, have no discernable user response time difference between SSL and non-SSL sessions.

There is a slight degradation in service process performance, but this is in the order of milliseconds. Again, largely ignorable when assessing the impact of SSL.

All our server-side code is written in C. Our web servers are (usually) IIS in production environments, and Xitami for development and demonstration purposes.

HeWhoMustBeConfused
Thursday, May 15, 2003

One gotcha to consider is whether you're planning on having documents that open directly into the browser. Some applications that dynamically stream the content (like, say, Adobe PDFs or QuickTime) might not support https, and if they're doing their own HTTP, you may also not get your cookies (meaning, possibly, no session data and therefore no correlation to a valid login).

Brad Wilson (dotnetguy.techieswithcats.com)
Thursday, May 15, 2003

A variety of user agents react poorly to mixed content.

http://www.whiterose.org/cluey/archives/002841.html
http://www.whiterose.org/cluey/archives/002918.html

Just one more thing to worry about.

Danil
Thursday, May 15, 2003

Secure connections are not cached at all, this can slow things down quite a lot (especially for repeat visits).
This is probably only noticeable on a dialup however.

Darren Greaves
Friday, May 16, 2003

Be carefull with the "SSL only for login" option (2).
Sometimes sites make the mistake of using "Basic authentication" (clear text username+password) protected by SSL for the login page, and switch to plain HTTP for the rest of the site (still under Basic authentication). Of couse they forget that the browser will still be sending the username + password for every request to that site.

Just me (Sir to you)
Friday, May 16, 2003

You can switch between secure and non secure pages if you like. Partition it carefully though. For example. Most web applications have session management, and if your cookies are holding on to plain text session IDs.. and these IDs literally will let someone hijack a highly sensitive privilaged operation (spending money at a online bank for example).. and direct himself into a SSLed transaction with your session key--then you lose. In the everyday fast paced web development we do everyday, we are presented with a threat model that leaves little room for good protection for session keys without the help of SSL.

Li-fan Chen
Friday, May 16, 2003

Sensitive data presented as pictures .. dynamic or static.. needs to be served over HTTPS, but other jpgs and gifs declassified can go over HTTP.

Li-fan Chen
Friday, May 16, 2003

HeWhoMustBeConfused:  Why do you use different web servers for production and development?  I realize CGI should be platform independent, but why introduce another variable when you don't need to?  What's the benefit of developing on Xitami?

Brian
Friday, May 16, 2003

Brian: Frankly, we'd prefer to deploy Xitami in production, but our customers are banks and won't look at anything that doesn't have big names associated with it.

We write our software to conform to established standards. CGI is really quite simple, and almost any web server can support our products. We like Xitami because it is small, simple, well supported, and it just works. It is great for demonstration platforms because of its low memory consumption and simple installation.

Ah, the money customers waste. We have a similar issue with database management. Our development servers are Adaptive Server Anywhere (Sybase) and Firebird (OS derivative of Interbase). These are great products which will support thousands of concurrent users of our application. They are low cost (or free, in the case of Firebird). But when the IT departments get involved in the selection of our software they INSIST on a DBMS such as Oracle, DB/2 or SQL/Server. Sure, we work with these produts, but the organisation throws away tens (hundreds, in some cases) of thousands of dollars on un-necessary bloat.

The usual argument is based around support, ie, "We are an Oracle shop and we need to be able to support this software".  Well, in over six years of application deployment in more than thirty customer sites, not ONCE has anyone from a customer IT department done any "support" associated with the DBMS. And the only "support" for the web server has been to patch repeated security holes, in MS-IIS installations.

And some IT managers wonder why they have a reputation for wasting money ...

HeWhoMustBeConfused
Friday, May 16, 2003

http://www.securiteam.com/windowsntfocus/6H00N200KK.html

Li-fan Chen
Sunday, May 25, 2003

*  Recent Topics

*  Fog Creek Home