Connect. Communicate. Collaborate. Securely.

Home » Kerio User Forums » Kerio Connect » Forward HTTP traffic to HTTPS?
  •  
JamesG

Messages: 22
Karma: 0
Send a private message to this user
I don't see this in the manual or forums...

I would like to turn off HTTP access, but I am not finding if and how Kerio forwards that traffic to HTTPS.

Sounds like it is a straight on or off, but I know it is possible in other software to forward all HTTP traffic to HTTPS.


Thanks,


James
  •  
metha

Messages: 11
Karma: 0
Send a private message to this user
Disable http service in Kerio. Set up IIS and set the default page to forward to port 443 where your Kerio will run https service.
Haven't tried this but it should work.
  •  
sedell

Messages: 1168
Karma: 1
Send a private message to this user
Why go through all that trouble. Change your security policy to either "Require secure authentication", or "Require encrypted connection", and KMS will handle the redirect automatically.

Scott
  •  
JamesG

Messages: 22
Karma: 0
Send a private message to this user
metha wrote on Sat, 05 May 2007 21:16

Disable http service in Kerio. Set up IIS and set the default page to forward to port 443 where your Kerio will run https service.
Haven't tried this but it should work.


Since we aren't running IIS, I will definitely go with Scott's method... :)
  •  
brsamuel

Messages: 17
Karma: 0
Send a private message to this user
Would "Require encrypted connection" also redirect POP3 users to POP3s & IMAP to IMAPs, etc.? And if their client were not set up for the secure connections, would they be redirected or dropped? If the "Require encrypted connection" were ONLY an HTML redirect to HTTPS, then it would be the obvious choice, but I'm a bit concerned about what might happen to users who are trying to connect with a client that is merely set up for POP3.

Samuel


  •  
sedell

Messages: 1168
Karma: 1
Send a private message to this user
"Require encrypted connection" is exactly that. HTTP traffic redirects to HTTPS, anyone trying to authenticate using POP3, IMAP, or SMTP without SSL enabled will have their authentication rejected - it can't redirect because there's nothing in the protocols to allow redirection.

"Require secure authentication" on the other hand, only requires secure authentication. For HTTP, this redirects to HTTPS to meet that requirement. I believe any authentication method that doesn't send the password in plain-text will work for POP3, IMAP, and SMTP. Cram-MD5, Digest-MD5, NTLM work. It depends on how your mail clients are configured whether or not they'll even notice that difference.

Scott
  •  
sedell

Messages: 1168
Karma: 1
Send a private message to this user
I forgot to mention that using SSL will also meet the requirements for "Require secure authentication". That comes in handy for certain e-mail clients that have trouble with alternate login methods.

Scott
  •  
brsamuel

Messages: 17
Karma: 0
Send a private message to this user
So, just to be sure I have it correct...

If I have my security policy set to either "Require secure authentication" or "Require encrypted connection", users accessing email through a browser will be conveniently redirected to an SSL encrypted page, everybody else is denied access unless their client is set up correctly.

Thanks
Samuel

  •  
shufflez

Messages: 12
Karma: 0
Send a private message to this user
So setting "Require encrypted connection", users have to change their KOC settings? They also have to add our SSL-certificate, but hey, the boss won't pay for a real one :).

And with "Require secure authentication" users will have to enter their passwords each time they fire-up Outlook+KOC?

So which one is the best choice? From a usability point of view the 'encrypted' version?
I'm wondering if both might be an option for some admins?
  •  
sedell

Messages: 1168
Karma: 1
Send a private message to this user
shufflez wrote on Wed, 09 May 2007 17:55

So setting "Require encrypted connection", users have to change their KOC settings? They also have to add our SSL-certificate, but hey, the boss won't pay for a real one :).


It's just one setting. On the advanced tab in the KOC setup window, just check Secure Connection (SSL). If you're on an Active Directory domain, you can deploy your certificate to domain computers. That's how we handled it when we still had a self-signed certificate. There was only one or two laptops we had to walk the user through importing the cert because they didn't get into the office before we threw the switch.
Quote:

And with "Require secure authentication" users will have to enter their passwords each time they fire-up Outlook+KOC?

No. "Require secure authentication" has nothing to do with entering a password, it has to do with how the mail client transmits the password - securely or insecurely. Several IFs here with this one. You can get away without SSL with KOC if you use active directory integration, and if the user is logged into the computer with their active directory account, you can use the "Secure Password Authentication" check box on the Account tab in setup. That will use the windows username/password to log in, and use NTLM authentication, which is secure. If you don't fall into that category, you'd have to use SSL.

Quote:

So which one is the best choice? From a usability point of view the 'encrypted' version?
I'm wondering if both might be an option for some admins?

That depends on what you're looking to accomplish. If you're only looking to protect passwords as they're transmitted, the secure authentication option will do the trick. If you want to encrypt communications between the mail client and server, use SSL. We force SSL because we've run into situations where mail from users on the outside was intercepted as they were sending mail. Requiring SSL put a stop to that.

Scott
Previous Topic: etrust antivirus does not load
Next Topic: importing pst file/folders empty.
Goto Forum:
  


Disclaimer:
Kerio discussion forums are intended for open communication between forum members and may contain information and material posted by members which may be useful in learning about Kerio products. The discussion forums are not intended to provide technical support for any specific product. Any information implied or expressed in the discussion forums is that of the posting member. Kerio is in no way responsible for the information posted in the forums, or its accuracy. Kerio employees may participate in the discussions, but their postings do not represent an offical position of the company on any issues raised or discussed. Kerio reserves the right to monitor and maintain the forums to promote free and accurate exchange of information.

Current Time: Mon Nov 20 05:01:56 CET 2017

Total time taken to generate the page: 0.00520 seconds
.:: Contact :: Home ::.
Powered by: FUDforum 3.0.4.