Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 1 year ago.
Improve this question
We have a webserver running behind AWS ALB and a AWS CloudFront in-front on ALB.
We have setup force http->https redirection in both CDN and ALB.
Do we still need to configure HSTS header ?
What are the disadvantages if we don't setup HSTS, when we have force https redirect enabled?
Consider the following attack (ssl stripping).
User enters "example.com" in the browser.
The browser sends request to http://example.com.
That redirects to https://
The browser requests https://example.com and all is well, right?
What if there is a man in the middle between the browser and these sites? HTTPS protects against man in the middle, so they can't do anything right?
User enters "example.com" in the browser.
The browser sends request to http://example.com.
Attacker hijacks this request and responds arbitrary content (eg. something that looks like the real one).
User entered example.com and got something that looks like it - user is happy, but is looking at a malicious page, on plain http. The attacker can even proxy the real page, replacing all https references with http, and serving appropriate content from a https site, the https connection in that case would be between the attacker and the https server, and not the user and the https server.
Of course the user can discover this if they are security aware and pay attention. Modern browsers now warn of insecure (=non-https) pages and so on. Still the best practice is to make the very first request on https too, so all this is not possible (because an attacker can't forge a valid certificate for https://example.com), and that's exactly what HSTS achieves.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last year.
Improve this question
It seems that more developers are using Charles Proxy nowadays, but I can't beg to differ what are the advantages or what you can do with Charles that you can't do with others like Chrome Developer Console or browser stack.
Debugging proxies like Charles Proxy, HTTP Toolkit and Fiddler all have a few features that browser developer tools don't:
They can capture traffic from non-browser sources, like mobile devices and desktop applications.
They can capture traffic from multiple tabs or other sources all in one place, so you can see the traffic from your web app and the backend traffic between your microservices all in one place.
They can capture traffic that the browser doesn't show - e.g. the browser's own requests for internal browser services, or safebrowsing checks, or CORS requests that don't appear in dev tools.
They include lots options to rewrite or reredirect traffic (usually with both custom rules to automatically mock responses and with breakpoints to manually edit traffic)
They usually offer more advanced traffic filtering and inspection, e.g. more powerful tools for finding certain requests, for inspecting more formats of request & response body, for understanding compression and caching behaviour, for validation of headers or even for validation of recognized request parameters with specific known APIs.
That said, there's a few unique benefits of browser tools:
There is zero setup and no separate applications required.
You immediately get the exact traffic from a single page with no extra noise from anywhere else.
They can use metadata from the browser's internal state, e.g. to show which line of JS sent a specific request, or to show requests that failed before any connections were made (due to CORS, mixed content, or many other browser restrictions).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 years ago.
Improve this question
Ours is a educational website collegesearch.in which is HTTPS secured. We are loosing our desktop traffic because we get error like untrusted certificate on public domain networks and also some of the antiviruses block our website as well. There is no issue with our certificate and they are issued by CSA and are not self-signed.
We understand some of the pages may include mixed content like stuffed http links, which we identify and remove but this itself does not seem to be the reason of traffic drop.
We have 75% mobile users and only ~20% of desktop, while our competitors have 40% of desktop users and they are http websites. This makes us think that using HTTPS has become ironically a problem.
My question is What makes antiviruses block HTTPS website?
Why we get untrusted certicate error?
Anything that can help here...
The site collegesearch.in:
is using a self-signed certificate and thus is not trusted by default by any browsers
on top of this the certificate is expired
on top of this the name in the certificate does not match the URL
on top of that you are offering insecure ciphers
For more details see the SSLLabs report.
Interestingly, www.collegesearch.in is setup in a different way although it still offers some weak ciphers.
It looks like that you are trying to deal with the badly setup collegesearch.in by redirecting users to www.collegesearch.in. But, for the redirect to work the user is first confronted with the bad certificate from collegesearch.in which he must accept before the browsers continues with the HTTP request which then results in the redirect to www.collegesearch.in. To fix this you need to have a proper certificate setup not only for www.collegesearch.in but also collegesearch.in.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
I have a website running on AWS that needs SSL. The website has the functionality that it must by white labelable according to the subdomain accessed. For example, when accessing www.a.the-site.com the website will look different from when it is accessed from www.b.the-site.com, but it is the same virtual host handling both urls. I use an ELB which directs to the EC2 instance (only one instance at this stage) This worked fine when running over normal http.
I followed the step by step tutorial on AWS (http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/ssl-server-cert.html and http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-create-https-ssl-load-balancer.html#configure-https-listener) to generate the keys (steps laid out below for ease of reference) and got the certificate from GoDaddy. (Upon pasting the CSR on the GoDaddy website's certificate request process, the correct CN was displayed). The certificate bought was a wildcard certificate, to support different subdomains. I applied the Certificate on the ELB using the AWS website interface, which did not prompt any errors, but now when I access the site over https, I get the SSL error in the browser:
"The security certificate presented by this website was issued for a different website's address."
Investigating the Certificate on https://www.sslshopper.com shows the following:
It states that none of the common names match, yet the common name in the chain is correct (*.the-site.com)
I can also post the steps followed to create the private key and CSR, but I have not received any indication that these are incorrect. It seems like the CN *.the-site.com is not resolving www.a.the-site.com. Can anyone shed some light on this?
#Michael - sqlbot was correct, the wildcard certificate only checks for a single domain. I changed my domain settings to not redirect to www.a.example.com, but rather a.example.com (dropping the www subdomain) and all is working as expected.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
Quick dumb question but want to make sure. I need to redirect www.example.com to www.example1.com. www.example1.com is already secured with a SSL cert. Do i need to purchase a SSL cert for www.example.com? I am assuming 'No' because the redirect is landing on a page that is aready secured.
Please advise.
Thanks,
Alpha
If you want to redirect from https://www.example.com to https://www.example1.com you need a certificate for www.example.com too. The redirect will be done with HTTP, but https encapsulates HTTP inside SSL. So it first needs to establish the SSL connection which includes verifying the certificate, before it can get to the HTTP layer with the redirect.
The ability to issue an HTTP-level redirect is independent of whether the original or destination sites are protected by HTTPS (SSL/TLS) and a corresponding certificate. Redirects may be issued in any combination, specifically all of these are allowed:
FROM TO
http://www.example.com http://www.other.example
http://www.example.com https://www.other.example
https://www.example.com http://www.other.example
https://www.example.com https://www.other.example
Before any of these HTTP redirects to take place, the client must be able to establish a valid HTTP request with the "FROM" server. If www.example.com is an Internet-accessible site intended to be used by anyone, and it uses HTTPS, then it must use a certificate; preferably, one signed by a recognized CA (Certificate Authority). However, this concern is not specific to the topic of redirects; it would apply to any request to that server and should be treated as a separate concern.
The answer to my interpretation of the OP's question is: No, the source of a redirect does not need to be secured with SSL/TLS merely in order to issue a redirect to a protected site. (Case 2 in my table above.)
There may be other reasons why the originating server should use HTTPS, but it is not a requirement merely for the ability to redirect. Note that in some cases (e.g. case 3) a browser may warn the user if redirecting to an insecure page from an HTTPS context.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'd like to authenticate the users to my website by checking their SSL client certificate information. I'm going to be using an Apache server, and I'd like to check that their certificates authenticate the users as members of certain organizations.
How can I do that?
In a nutshell:
Obtain an SSL Certificate for whichever domain you need, this could be the main domain, subdomain, wildcard, etc. If your going to have multiple subdomains then a wildcard is the way to go. SSL Certificates can be purchased from most hosting companies, for example 123-reg provide them.
Install Certificate on Apache, depending on OS platform this could be via updating httpd.conf or ssl.conf to reference the SSL Certificate, key, pem files, etc. You will need to modify the various SSLCertificate... directives, take a look at ssl.conf for the example configuration.
Setup whatever authentication you require for Apache hosted site, for example, setup the users using htpasswd.
End users then need to install the certificate upon first connecting to the https site, this is done client side and may require admin rights to add to client PC.
Most certificate providers give full installation instructions.