The SecureRequestCustomizer allows us to get the certificate(s) in the HTTP request. This setting is active for the whole jetty server (all URLs). So as soon as one requests any page from the server, the browser will ask what certificate to use.
Is it possible to have only a specific URL request the client certificate?
I would like to have a dedicated /webapp/login-cert URL that would trigger the browser popup to pick a certificate.
Related
I have recently had an active website that was protected by an SSL certificate. The site is no longer active and the certificate has expired. I have tried to put up a simple HTML holding page but Google will not show it because there is an expired certificate associated with the domain. Is there a solution to allow me to display the page without needing a certificate.
You don't mention what web server or hosting platform you are using. In general yes you can remove an SSL certificate (and stop listening on port 443). But bear in mind if the user has saved a bookmark starting HTTPS, or the links to the site are HTTPS, or if you used the HSTS header to indicate the site should always be viewed over HTTPS then visitors will have trouble viewing the page only accessible over HTTP.
Given you can get a certificate from LetsEncrypt at no cost the most straightforward, and visitor friendly, option would be to renew the certificate.
In one of projects we use CloudFlare and its cf-connecting-ip header to get a visitor IP address. But I'm not sure that the info can be fully trusted. For example, a bad user somehow had obtained real IP of our server, and connecting directly to it, putting fake IP address to the cf-connecting-ip header, and pretending that it was a legitimate CF-proxied request.
I examined headers for CF-proxied requests, and saw the cf-request-id header. But it's unique per a request, and I cannot see there any fixed secure key which I can use to verify that the request was legitimate.
How to ensure that a request was really proxied by CF?
You may want to use the Authenticated Origin Pulls feature from Cloudflare:
Authenticated Origin Pulls let origin web servers strongly validate that a web request is coming from Cloudflare.
We use TLS client certificate authentication, a feature supported by most web servers, and present a Cloudflare certificate when establishing a connection between Cloudflare and the origin server.
By validating this certificate in origin server configuration, access can be limited to Cloudflare connections.
You will need to download the client certificate from Cloudflare and configure your webserver to enforce the certificate check.
The referenced page has instructions on how to set up client certificate in Apache and Nginx.
I was trying to get myself familiarised with basic concepts of https when I came across its encryption, which in a nutshell functions as follows,
Now I have seen QA engineers in my company use this tool called burp-suite to intercept request.
What I am confused about is even though the data flows through an encrypted channel, how can any interception tool like burp-suite manage to intercept the request.
Just to try it out I tried to intercept facebook request in burp-suite,
Here you can clearly see the test email test#gmail.com I used in the intercepted request.
Why is this data not encrypted according to https standards?
Or if it is then how do burp-suite manage to decrypt it?
Thank you.
Meta: this isn't really a development or programming question or problem, although Burp is sometimes used for research or debugging.
If you LOOK AT THE DOCUMENTATION on Using Burp Proxy
Burp CA certificate - Since Burp breaks TLS connections between your browser and servers, your browser will by default show a warning message if you visit an HTTPS site via Burp Proxy. This is because the browser does not recognize Burp's TLS certificate, and infers that your traffic may be being intercepted by a third-party attacker. To use Burp effectively with TLS connections, you really need to install Burp's Certificate Authority master certificate in your browser, so that it trusts the certificates generated by Burp.
and following the link provided right there
By default, when you browse an HTTPS website via Burp, the Proxy generates a TLS certificate for each host, signed by its own Certificate Authority (CA) certificate. ...
Using its own generated cert (and matching key, although the webpage doesn't talk about that because it isn't visible to people) instead of the cert from the real site allows Burp to 'terminate' the TLS session from the client, decrypting and examining the data, and then forwarding that data over a different TLS session to the real site, and vice versa on the response (unless configured to do something different like modify the data).
... This CA certificate is generated the first time Burp is run, and stored locally. To use Burp Proxy most effectively with HTTPS websites, you will need to install Burp's CA certificate as a trusted root in your browser.
This is followed by a warning about the risks, and a link to instructions to do so.
Having its own CA cert trusted in the browser means that the generated cert is accepted by the browser and everything looks mostly normal to the browser user (or other client).
I am testing SSL on the localhost server.
It looks like HTTPS is displayed in the address bar and it seems to be successful HTTPS communication.
However, when I use ZAP to break the request and response, and see them the contents are just plain text.
Is this the right thing?
As the https part of the URL has a red line across it I'm guessing you launched the browser from ZAP. When you do that ZAP configures the browser to proxy via ZAP and ignore certificate warnings. ZAP can then use its CA certificate to intercept and re-sign the request.
I want to build a desktop app, which accepts triggers from the browser (my web application runs in https). As a solution i have implemented self hosting web api with OWIN which uses self signed certificate.
Registered the certificate for https using netsh command
netsh http add sslcert ipport=0.0.0.0:4443 certhash=40514d4576059d0c1c205c7b820cc0a407915b65 appid={163ea903-b9fd-4019-9c5c-7cdf158111a6}
Now when i try to send http request, browser complains that the certificate is not valid.
https://localhost:4443/api/download
Is it possible to create/buy valid certificates for localhost? (my app will be running on different user machines) Is there any other way i can solve my situation ( solving browser to local app communication)?
Basically i found that we cannot self host webapi in https. Because we cannot get a SSL for localhost, browser will not allow http request to that.