[imp] Running IMP on the internet

[Eric Rostetter]

Quoting eltonic40@ecotech.com.lr:

> Eric,
> 
> But doesn't keeping SSL always on burn out? 

I don't know what that means.  But the issues with ssl on are:

1) All your web servered transactions are encrypted.
If you have sensitive content in your web traffic (grades at 
a university, medical records in a hospital environment, crime info in
law enforcement, etc) then this is a good thing.

2) It is a performance hit on your machine, so you need to have a machine
that can handle the load, or a way to offload that to another device 
(ssl accelerators, proxies, etc)

> I have an SSL enabled Apache Web
> Server and give SSL and non-SSL access to IMP.

That is reasonable for some people to do.  The most important thing to
protect is passwords (login screen, passwd module if you use it, fetchmail
patches released yesterday, the redirection page, etc).  All the other pages 
that don't have password data passed around may be reasonable to leave open.

I realize a lot of people are happy to only ssl encode the pages the use
passwords or other sensitive information.  My problem with that is that it
may be hard to decide which pages need encryption (you may forget some)
and then every time you add pages (new patches, updates, modules, etc) you
have to go through again and decide if new/renamed pages need to be encrypted
and go through the configuration setting it up again.  I always thought it was
easier to just encrypt everything and rest assured that it is all going to
be safe all the time.

> I realize that when using SSL, 
> after a while of transactions, I get PAGE CAN'T BE DISPLAYED! However when I 
> use non-SSL access, I don't get this error!

I never get that message -- ever -- and all my stuff is encrypted.  This holds
for two different servers running totally different apps.  I've no complaints
from the thousands of users using my services about any such error.
 
> How about putting up SSL access on the login and leaving the rest non-SSL?

See above.  Many other pages besides login may need SSL.  It is a bit of work
to track them down, configure them, and keep on top of it as you update things.
But if you want to do this, or you don't have the horsepower to do it all
ssl, then this may be a way to go, and is a reasonable alternative to making
everything encrypted.

I'm keeping the part of my previous message intact below which tells some ssl 
apache config lines that I use to stop browser bugs from showing up on my ssl 
sites.  Your millage may vary.  But I will repeat: I run two very high 
volume ssl only web sites, and other than the fact that MAC MSIE browsers
back buttons misbehave in ssl mode, I have absolutely no problems.  

Now, I admit, it took me a few weeks to arrive at the proper setup to support
all browsers, and that until I did we had problems with various browsers not
working right. But once I got it working it has worked ever since, even 
through web server, OS, and browser upgrades.  And this is with sites used 
by thousands of users all over the world on a daily bases. So, it *can* work.

> eltonic40
> 
> 
> Quoting Eric Rostetter <eric.rostetter@physics.utexas.edu>:

> > SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
> > 
> > If you are having trouble, you might also try adding:
> > 
> >   SSLProtocol all -SSLv3
> >   SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP

-- 
Eric Rostetter
eric.rostetter@physics.utexas.edu

Hey Rocky!  Watch me pull a rabbit from my hat!