In an application we are writing we need to have a page that is essentially public but should only be available to certain people.. yep i know very paradoxical!
Its basically a "Submit a support ticket" style page that is hosted outside of a customers intranet but should only be available to users on that intranet.
Naturally making the user sign up for an account is the usual course of action but in this case it isn't really an option..
Is there any way of doing a "secure redirect" to that page?
My initial though would be to use an internal page which redirects appending a unique one time hash to the url which expires and then although its not 100% airtight it is only valid for about 1 min..
Two ways come to mind.
1) Deploy IP restrictions on the web server for the off-network resource. If the request is coming from one of the exit points from your network (proxy server, other public-facing egress points, etc) then allow the connection, otherwise do not.
2) Deploy mutually authenticated SSL on both the web server and a reverse-proxy server on your internal network. Clients connect to the internal reverse-proxy and that proxies them back to the external resource over an SSL connection that is mutually authenticated (so the external web server will only connect over SSL and it will only connect to a client (the reverse-proxy in this case) that has a recognized/accepted client certificate).
"Secure Redirect" is meaningless. What you want to do is make sure your ticket submit system will only accept clients connecting from your users' network. This would be a web site configuration thing.
Related
I use Nginx to manage a lot of my web services. They listens different port, but all accessed by the reverse proxy of Nginx within one domain. Such as to access a RESTful-API server I can use http://my-domain/api/, and to access a video server I can use http://my-domain/video.
I have generated a SSL certificate for my-domain and added it into my Nginx conf so my Nginx server is HTTPS now -- But those original servers are still using HTTP.
What will happen when I visit https://my-domain/<path>? Is this as safe as configuring SSL on the original servers?
One of the goals of making sites be HTTPS is to prevent the transmitted data between two endpoints from being intercepted by outside parties to either be modified, as in a man-in-the-middle attack, or for the data to be stolen and used for bad purposes. On the public Internet, any data transmitted between two endpoints needs to be secured.
On private networks, this need isn't quite so great. Many services do run on just HTTP on private networks just fine. However, there are a couple points to take into consideration:
Make sure unused ports are blocked:
While you may have an NGINX reverse proxy listening on port 443, is port 80 blocked, or can the sites still be accessed via HTTP?
Are the other ports to the services blocked as well? Let's say your web server runs on port 8080, and the NGINX reverse proxy forwards certain traffic to localhost:8080, can the site still be accessed at http://example.com:8080 or https://example.com:8080? One way to prevent this is to use a firewall and block all incoming traffic on any ports you don't intend to accept traffic on. You can always unblock them later, if you add a service that requires that port be opened.
Internal services are accessible by other services on the same server
The next consideration relates to other software that may be running on the server. While it's within a private ecosystem, any service running on the server can access localhost:8080. Since the traffic between the reverse proxy and the web server are not encrypted, that traffic can also be sniffed, even if authorisation is required in order to authenticate localhost:8080. All a rogue service would need to do is monitor the port and wait for a user to login. Then that service can capture everything between the two endpoints.
One strategy to mitigate the dangers created by spyware is to either use virtualisation to separate a single server into logical servers, or use different hardware for things that are not related. This at least keeps things separate so that the people responsible for application A don't think that service X might be something the team running application B is using. Anything out of place will more likely stand out.
For instance, a company website and an internal wiki probably don't belong on the same server.
The simpler we can keep the setup and configuration on the server by limiting what that server's job is, the more easily we can keep tabs on what's happening on the server and prevent data leaks.
Use good security practices
Use good security best practices on the server. For instance, don't run as root. Use a non-root user for administrative tasks. For any services that run which are long lived, don't run them as root.
For instance, NGINX is capable of running as the user www-data. With specific users for different services, we can create groups and assign the different users to them and then modify the file ownership and permissions, using chown and chmod, to ensure that those services only have access to what they need and nothing more. As an example, I've often wondered why NGINX needs read access to logs. It really should, in theory, only need write access to them. If this service were to somehow get compromised, the worst it could do is write a bunch of garbage to the logs, but an attacker might find their hands are tied when it comes to retrieving sensitive information from them.
localhost SSL certs are generally for development only
While I don't recommend this for production, there are ways to make localhost use HTTPS. One is with a self signed certificate. The other uses a tool called mkcert which lets you be your own CA (certificate authority) for issuing SSL certificates. The latter is a great solution, since the browser and other services will implicitly trust the generated certificates, but the general consensus, even by the author of mkcert, is that this is only recommended for development purposes, not production purposes. I've yet to find a good solution for localhost in production. I don't think it exists, and in my experience, I've never seen anyone worry about it.
I'm planning an API that will be used by a client on their internal office networks in multiple separate locations. Each location will have a separate instance installed.
They want it to be secure and running on HTTPS.
What I cant seem to understand how can a HTTPS certificate work when there is no externally facing fully qualified name. eg. MyApiServer.mycompany.com
Instead they will likely just be running it on a server/computer with just a hostname. ie. MyApiServer
The data being transferred is not necessarily sensitive but it places records in a sales system.
If HTTPS is not possible in this scenario whats an alternative method to secure the communication?
The server name has not to be "fully-qualified". For securing the call it will be enough to have the domain specified in URL equal to the domain name specified in certificate.
So your clients would call https://MyApiServer/endpoint in your LAN which should cause your service to provide server certificate where the subject would be MyApiServer.
I have deployed an OpenVPN server from GCP market Place and have attached a Domain name to it along with the SSL certificate. Currently, I am able to access the server through both
https://domain-name.com
https://x.x.x.x -(Server Static Ip)
I want the server to be accessible only through the hostname and not its Server IP as the latter URL gives an SSL security error as the SSL certificate is attached to the Domain name and not to the server IP.
Can anyone help me to restrict it or give some advice to solve it?
You could try to do it(prevent access by IP) but I advice you to not try to do it.
Theoretically it could be possible for your HTTP server to reset SSL connection when browser sends "wrong" SNI(Server Name Indication) in a handshake.
Thus you could prevent your browser displaying security alerts.
Instead your browser would show network error message.
I doubt you would like to trade one type of error to another one.
I suggest you to do nothing about such "error" because legitimate visitors will come to your site via domain name and will not see such security warning.
Also there is huge possibility that legitimate visitor (with paranoid mindset) will use browser with SNI feature disabled so your server will not be able to make difference between good and bad URLs.
PS: here are relevant questions and discussions at reddit and at ServerFault and another one
i m using Weblogic 12c.
I would like to set up client certificate authentication (2-way SSL). But i do not want to enforce client certificates for the whole server. Basically, in our webapp most of the servlets should work with regular 1-way SSL (only server certificate is verified) without requiring client to provide the certificate. But for one of the servlets client certificate authentication is needed.
I have set up similar thing for Glassfish using separate module for the servlet where 2-way SSL is required with web.xml deployment descriptor with login-config element indicating CLIENT-CERT authentication type. I have also set up appropriate security constraints, roles and groups.
However this does not seem to work with Weblogic. In the admin console under SSL i see "Two Way Client Cert Behavior" with 3 possible values: "client cert not requested", "requested but not enforced" and "requested and enforced".
If i set it to "not requested", client does not present any certificates at all (even though i have the same web.xml with CLIENT-CERT which works with Glassfish). Setting to "requested and enforced" is not an option. I also tried setting to "requested but not enforced" but that's also bad since the browser will ask for client certificate even for those pages where it is not needed (most of them) and we don't want that behavior.
Basically, it seems to me that Weblogic wants to enforce 2-way SSL for the whole server, but that's not what we need, we need it only for one webapp module. Is it possible to do so?
Edit:
To clarify, i set up DefaultIdentityAsserter and created custom UserNameMapper to map client certificate to user name. The problem however that if SSL setting (described above) is set to "not requested" then client certificate is not presented at all so the server cannot authenticate and i get 401 response. And i can't use the other 2 SSL settings because then the server will ask for client certificate for all webpages and that's not what we want.
You could create 2 Network Channels. See NetworkAccessPointMBean in WLST, or Environment/Servers/yourServer/Protocols/Channels in Admin Console.
Channel 1: SSL enabled w/ one-way SSL, on a specific port
Channel 2: SSL enabled w/ two-way SSL and client cert enforced, on a specific port
Then, access your web module on the appropriate port based on your client cert requirements.
This would only require one server.
For your specific need, I would create 2 managed servers, setting up only one with 2 way SSL.
You can then deploy your applications on the appropriate managed server, depending if you want the 2 way SSL or not for it.
Then you need to add a reverse proxy in front of your WebLogic server in order to forward your user to the correct port, as you probably don't want to expose several ports.
I've developed a web app, which uses HTTPS and which works fine when I access is it (live). Yet some customers, who use proxy servers, can't access the site. I already tried to use a real certificate (a cheap one and only a trial, but yet valid), but that didn't help.
Everytime one of these users tries to access the site the browser tries to load it until a timeout occurs. One user even was shown an authentication (but I'm not 100% sure if this was due to a proxy, still waiting for response from the customer)
For which reasons can this happen and what can I do about it?
I'm using IIS, ASP.NET (C#) and JS. Sideinfo: The URL contains a port, the internal structure of the network the IIS is running in (not mine) doesn't allow it otherwise.
443 is dedicated port for HTTPS connectivity. Add type 'HTTPS' with default port 443 in Site bindings of hosted site directory. Check after whether SSL is enabled or not? in IE(browser)->Tools->Internet options->Advanced->Security.
If the HTTPS port in your web app's URL isn't port 443, you'll have a problem with corporate proxies that don't like non-standard HTTPS ports.
i.e. I hope your URL looks something like this: http://example.com:443/...