I enabled Use HTTPS for logins in HTTP Security. It works fine when I enter root address (mymoodlewebsite.com). Unfortunately it is possible to login through unsecured connection in two cases:
When session expires - Moodle asks for credentials via http login page (http:// (...) /login/index.php)
It is possible to change protocol in address bar from https to http.
After login communication is not encrypted (It should be this way).
I use Debian/Apache server.
What should I do to eliminate possibility of insecure login?
Maybe you could resolve this problem by using an Apache redirect. Create a file in login folder and name it .htaccess, then insert these lines:
# HTTP 301 redirect
RewriteEngine On
RedirectMatch 301 ^/login/login\.php$ https://%{HTTP_HOST}/login/login.php
You must have the rewrite module enabled, otherwise this solution won't work.
add this code in your moodle/config.php file
$CFG->loginhttps=false;
Related
We want to ensure all sites hosted on apache web server all protected using htpasswd (Apache Basic Authentication)
There are a few sites which are redirected from http to https, and the above authentication goes into a redirect loop on HTTPS (on further,related reading it seems that HTTP basic authentication compares the password (encrypted) format in plain text)
We have tried several samples/snippets to make basic authentication prompt work on HTTPS, but every code snippet results into multiple redirect loop and back to Auth prompt even when I key the correct password.
The links that I have already referred are : Apache .htaccess redirect to HTTPS before asking for user authentication
https://webmasters.stackexchange.com/questions/8853/properly-force-ssl-with-htaccess-no-double-authentication
Do HTTP authentication over HTTPS with URL rewriting
We have tried all the combinations SSLRequireSSL, writing it in other VirtualHost, but nothing seems to work as site redirects from HTTP to HTTPS during the Authentication, Furthermore, there are no error logs of any kind, so it implies the .htaccess and apache config is fine.
SSL,rewrite,auth etc modules are already enabled on the server
I have recently setup a SSL certificate to my domain. Installation was successful. Post installation when i opened https it showed a Internal Server error'The server encountered an internal error or misconfiguration and was unable to complete your request.' at the same time when i opened http it worked fine.
Then i have made a change in my htaccess file adding
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</ifModule>
to it. Now http is redirected to https but still am getting same Internal server error.
I checked my error log i found error
[warn] RSA server certificate CommonName (CN) `www.dimain.com' does NOT match server name!?
Please help me how to solve this.
Thanks.
May I suggest also using HTTP Strict Transport Security (HSTS) in addition to the other suggestions... :-)
http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
From https://drupal.org/https-information:
Drupal configuration
If you want to support mixed-mode HTTPS and HTTP sessions open up sites/default/settings.php and add $conf['https'] = TRUE;. This enables you use the same session over HTTP and HTTPS both -- but with two cookies where the HTTPS cookie is sent over HTTPS only. You will need to use contributed modules like securepages to do anything useful with this mode, like submitting forms over HTTPS and so on. While your HTTP cookie is still vulnerable to all usual attacks, a hijacked insecure session cookie can only be used to gain authenticated access to the HTTP site. It will not be valid on the HTTPS site. Whether this is a problem or not depends on the needs of your site and the various module configurations. For example, if all forms are set to go through HTTPS and your visitors can see the same information as logged in users then this is not a problem.
For even better security, leave $conf['https'] at the default value (FALSE) and send all authenticated traffic through HTTPS and use HTTP for anonymous sessions. Once again contributed modules like 443 Session or Secure Login can help you here. Drupal 7 automatically enables the session.cookie_secure PHP configuration on HTTPS sites, which causes SSL-only secure session cookies to be issued to the browser.
For best-possible security, setup your site to only use HTTPS, not even responding to HTTP with a redirect. HTTPS is vulnerable to man-in-the-middle attacks if the connection starts out as a HTTP connection before being redirected to HTTPS. $conf['https'] can be left at its default value (FALSE) on pure-HTTPS sites. You can run the HTTP site from a different server and simply deliver a plain text message telling your users to use HTTPS.
It's a problem with your certificate not with your redirection or drupal.
Perhaps your certificate it's for yourdomaine.com and you try to access www.yourdomaine.com . If you want to access both you will need a wildcard certificate.
I have installed ssl certificates on my site but the browsers still showing unsafe connection. However i can access a safe connection by using https:// before site url
If you want to force https you'll need to set that up.
As explained on the apache wiki the recommended method is to setup the http virtual host to redirect to the https virtual host. Alternatively, you can use mod_rewrite to redirect from http to https.
I'm using .htaccess to protect a website at http://www.domain.com. Secure pages redirect to https://www.domain.com, and get the apache login prompt again.
How can we have only 1 apache login prompt for both http and https?
Thank you very much.
You can't. As far as the browser is concerned, http: and https: are two different websites, and you won't get it to tell the https: site which password the user entered for the http: site. Doing so would be a serious security bug in general, and the HTTP authentication protocol is not advanced enough to allow the http: server to tell the browser, "it is OK to repeat this password for such-and-such site". (And why would you trust a security exception given to you by a mere http: site anyway?)
Why don't you just do everything over https?
Or, put differently, why do you do anything that requires authentication over plain HTTP? That's not very secure. And if you have something on the https site that deserves https security, an attacker could just sniff the passwords from the insecure http connections.
I'm pulling my hair out on what should be an insanely simple problem. We are running WebSphere IHS (Apache) through an F5 BigIP. BigIP is doing the https translation for us. Our url (changed for web, not valid) is https://superniftyserver.com/lawson/portal.
When someone types in just that without the slash after portal, Apache assumes "portal" to be a file and not a directory. When Apache finds out what it is, it sends the 301 Permanent Redirect. But since Apache knows only http, it sends the URL as http://superniftyserver.com/lawson/portal/ which then creates problems.
So I tried a server level httpd.conf change for mod_rewrite, this is one of the dozens of combinations I've tried.
RewriteEngine on
RewriteRule ^/lawson/portal(.*) /lawson/portal/$1
I also tried
RewriteRule ^/lawson/portal$ /lawson/portal/
Among many other things... What am I missing?
If you can't get an answer on the RewriteRule syntax, here are two other options for you: Write an custom iRule on BigIp (see F5 DevCentral) that looks for 301 responses and convert them to SSL; let the URL pass into your WebSphere server and do a programmatic redirect that sends out HTTPS. However, because F5 terminates the SSL connection, you have to set a custom header that you configure (see PQ86347) so the Java request.getScheme() works as you would expect.
Fixed!
SOL6912: Configuring an HTTP profile to rewrite URLs so that redirects from an HTTP server specify the HTTPS protocol
Updated: 8/7/07 12:00 AM
A ClientSSL virtual server is typically configured to accept HTTPS connections from a client, decrypt the SSL session, and send the unencrypted HTTP request to the web server.
When a requested URI does not include a trailing slash (a forward slash, such as /, at the end of the URI), some web servers generate a courtesy redirect. Without a trailing slash, the web server will first treat the resource specified in the URI as a file. If the file cannot be found, the web server may search for a directory with the same name and if found, send an HTTP 302 redirect response back to the client with a trailing slash. The redirect will be returned to the client in HTTP mode rather than HTTPS, causing the SSL session to fail.
Following is an example of how an HTTP 302 redirect response causes the SSL session to fail:
· To request an SSL session, a user types https://www.f5.com/stuff without a trailing slash.
· The client browser sends an SSL request to the ClientSSL virtual server, which resides on the BIG-IP LTM system.
· The BIG-IP LTM system then decrypts the request and sends a GET /stuff command to the web server.
· Since the /stuff file does not exist on the web server, but a /stuff/ virtual directory exists, the web server sends an HTTP 302 redirect response for the directory, but appends a trailing slash to the resource. When the web server sends the HTTP 302 redirect response, it specifies HTTP (not HTTPS).
· When the client receives the HTTP 302 redirect response, it sends a new request to the BIG-IP LTM virtual server that specifies HTTP (not HTTPS). As a result, the SSL connection fails.
Configuring an HTTP profile to rewrite URLs
In BIG-IP LTM version 9.x you can configure an HTTP profile to rewrite URLs so that redirects from an HTTP server specify the HTTPS protocol. To do so, perform the following procedure:
Log in to the Configuration utility.
Click Local Traffic.
Click Profiles.
Click the Create button.
Type a name for the profile.
Choose http from the Parent Profile drop-down menu.
Under Settings, set Redirect Rewrite to All, Matching, or Nodes, depending upon your configuration
For example:
o Choose All to rewrite any HTTP 301, 302, 303, 305, or 307 redirects to HTTPS
o Choose Matching to rewrite redirects when the path and query URI components of the request and the redirect are identical (except for the trailing slash)
o Choose Node to rewrite redirects when the redirect URI contains a node IP address instead of a host name, and you want the system to change it to the virtual server address
Click Finished.
You must now associate the new HTTP profile with the ClientSSL virtual server.
Try this:
# Trailing slash problem
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} -d
RewriteRule ^(.+[^/])$ https://<t:sitename/>$1/ [redirect,last]
LoadModule rewrite_module modules/mod_rewrite.so
make sure that line is somewhere in you httpd.conf file
RewriteEngine on
RewriteCond %{REQUEST_URI} ^/lawson/portal$ RewriteRule ^(.*)$ https://superniftyserver.com/lawson/portal/ [R=301,L]