I want to redirect all users still using SSLv2 and SSLv3 to a specific page and users with no SSLv3 protocol (TLS 1.x) will no redirect to the page.
So how do I detect these SSLv2-SSLv3-only users from IIS? and put in place the redirection.
Related
To set up enrollment for Windows devices Microsoft suggests to set up CNAME for enterpriseenrollment.company-domain.com and enterpriseregistration.company-domain.com to specified Microsoft domains: https://learn.microsoft.com/en-us/mem/intune/enrollment/windows-enroll.
If company-domain.com has configured Strict-Transport-Security (HSTS) for all subdomains this will force https, and as a valid certificate for the mentioned CNAME subdomains doesn't exist at the Microsoft sites, certificate validation will fail in browsers.
Is all relevant usage of enterpriseenrollment and enterpriseregistration done with clients that don't care about HSTS (not browser based) or make exceptions for these sites?
I need to redirect a URL f.e. https//domain1.nl/sub1/sub2 (from an old exprired ssl certificate) to a new active domain f.e. https//domain2.de/sub1/sub2 with a new and active ssl certificate with php or htaccess rules.
is this possible without getting an security warning from the browsers?
Greeting
Jimbob
Both of these require server to send redirect which happens after the certificate is validated. So no.
I am totally stumped on this one. I recently installed SSL certificates on my site and SSL terminates at my load balancer, HAProxy. So far all of my regular users are able to use the secure connection except for those behind one major corporate network.
Those behind the network get this message in Chrome:
"This webpage is not available" "The
webpage at https://example.com/ might be temporarily down or it may
have moved permanently to a new web address."
Error Code: ERR_CONNECTION_CLOSED
They can access http://example.com site just fine (no SSL) if I enable it.
I was originally wondering if it was an issue with my ciphers, but these corporate users cannot access files on static server either (using AWS Cloudfront with SSL certificate).
I'm guessing the firm may have a blanket ban on SSL certificates unless there is a whitelist? They can access the ssl site of google (https://google.com). Is there something wrong with my certificate? Chrome has a green lock and says my site uses modern cryptography.
Anyway, is there anyway to determine if they can't access my site via SSL and then redirect them to use the nonsecure version? I tried looking through HAProxy docs but am missing something and at this point have tunnel vision.
Thanks to all. Here is my config file:
global
tune.ssl.default-dh-param 2048
ssl-default-bind-options no-sslv3
ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
mode http
option forwardfor
option http-server-close
option http-pretend-keepalive
timeout client 120s
timeout connect 10s
timeout tunnel 120s
timeout client-fin 120s
timeout server 120s
frontend https-www
bind *:443 ssl crt /etc/ssl/example_com/example.com.pem
#using naked domain
redirect location https://example.com if { hdr_beg(host) -i www }
acl is_sockjs path_beg /sockjs
use_backend sockjs if is_sockjs
default_backend django
frontend all
bind *:80
#How do I detect that the ssl site failed for them?
redirect scheme https if !{ ssl_fc }
backend sockjs
reqadd X-Forwarded-Proto:\ http
balance leastconn
cookie SERV_ID prefix nocache
server srv_sockjs1 sockjsserver-ip check cookie s1
backend django
reqadd X-Forwarded-Proto:\ https
balance roundrobin
server srv_static django-server-ip
backend django-nonssl
reqadd X-Forwarded-Proto:\ http
balance roundrobin
server srv_static django-server-ip
OK figured it out
It was related to the naked domains. The server didn't like the fact that I redirected https://www.example.com to https://example.com. Upon further reading, I am going to now do the opposite, where I don't support naked domains and now redirect https://example.com to https://www.example.com
I had to do this on cloudfront too, where I now use www.subdomain.example.com instead of example.com
Is there improved security with web applications if you use "Require SSL" in the SSL Setting section of IIS? I was planning on creating a URL Rewrite rule.
"Require SSL" will cause a 403.4 Forbidden response if you try to access the site using http://example.com. It won't automatically redirect to the https:// url.
This may be confusing for users if you're not linking in some way to the https://example.com SSL'd url.
If you want users to be able to randomly hit the site using plain http:// and then redirect them to the SSL'd url then you're better off leaving "Require SSL" turned off and do a rewrite.
Say you only want to send cookies over HTTPS to the client - not over HTTP. You could use the HTTP secure flags as mentioned in this article. However, since you can use the Apache mod_rewrite module to send a redirect to the user from the HTTP version of your site to the HTTPS version, shouldn't that mean that it will secure the cookies? In other words, does the server send your cookies if its sending out a redirect?
If you are redirecting from HTTP to HTTPS and then set cookies, these cookies will be set over HTTPS. Say you redirect the user from http://www.example.com to https://www.example.com, the Set-Cookie header sent from www.example.com to the user will be encrypted during transport.
However, if the user comes back and enters http://www.example.com in their browser, if the Secure Flag was not set on the cookie, the cookie will be sent over HTTP, unencrypted.
This can also happen if any internal links on your site are HTTP, any links on other sites to yours are HTTP or if a MITM attacker injects a HTTP resource from your site on another site (e.g. <img src="http://www.example.com/x.jpg" /> will leak the cookie over HTTP).
This is why it is advisable to set the secure flag. HSTS can be used to help ensure connections remain on HTTPS only, however setting the secure flag should be the primary focus.