For an embedded device under development we have a requirement for logging in to its web without sending user credentials in clear text.
The look of the log in form should be customizable, so digest authentication is not possible. The only remaining option as we see it, is to use HTTPS with SSL.
The device is usually accessed from the local network by it's IP address, but could also be made accessible from the internet.
My question is: Is it at all possible to prevent the "Could not be certified" browser warning, when no DNS name is assigned to the locally accessed device? As I see it, a SSL certificate must be bound to a DNS name and certified at a Certificate Authority for the browser to fully accept the certificate.
I am fully aware of the fact that without a certified certification the browser can not authenticate the web server, which could lead to a "man-in-the-middle" attack.
When the device is fully configured it's only accessed very rarely, but it should be easily accessible.
HTTPS does allow for a certificate to be issued to an IP address instead of a hostname. Indeed, the HTTPS specification (RFC 2818) states "In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI."
So, if you can obtain an SSL/TLS certificate from a CA that is bound to the IP address of your device, then clients connecting to it should accept it as valid as (1) the URI used to access the device is the IP address that matches that contained within the certificate, and (2) the certificate is issued by a CA chain trusted by the client device.
If you only need to access this device using clients that you control, you can use a self-signed, bound to the IP address, certificate that you generate, but you would need to configure each client that would access it to explicitly trust that certificate since it would not be issued by a trusted CA.
Related
I'm learning the process of authentication in PKi environement.
Imagine I have two web servers (example IIS) that are configured with same TLS certificate to bind websites.
Now, if I remove and add a new certificate on one of two servers. It's still have the same common name but generated with a different private key.
I wonder if having two certificate with the same common name (subject) with two different private keys will be a problem?
What information is used by the client to choose a specific public key to encrypt information?
I hope that my question is clear. Let me know if you need more information.
Many thanks for your help.
No matter how many certificates you installed to Windows certificate stores, IIS only uses the mappings in Windows HTTP API to determine the actual server certificate to use for a specific site,
https://docs.jexusmanager.com/tutorials/https-binding.html#background
If you are familiar with SSL/TLS handshake process, you can easily see in that way the browser always knows which public key to use.
Will it be a problem? The answer is maybe.
Assuming a modern browser, then the PKI works broadly like this:
the browser first uses DNS to resolve the FQDN into an address;
then the browser sends a TLS client hello to it, which contains an
SNI matching the FQDN;
the server receives the TLS client hello, checks whether the FQDN matches ones it owns, then responds with a TLS server hello containing the X.509 certificate;
the browser receives the TLS server hello, then checks that the certificate is valid;
that the SubjectAltName (SAN) field contains the FQDN (SAN has replaced
CN); and
that the certificate is signed by a CA that it trusts.
At this point the browser doesn't actually care whether you have multiple servers with multiple different certificates (which can be normal during a patch where they are being revoked and replaced).
The maybe comes afterwards, because there are a collection of HTTP extensions that can cause the browser to reject the certificate if it does not comply with what it is expecting, such as Expect-CT and HSTS.
I have local server in my home, which runs website, which provides some service, thanks the use of PHP. Right now I'm using the HTTP protocol, which doesn't not provide security, due to the clear-text (the is a authentication service with username and password to access the protected page). I want to upgrade to HTTPS and of course I need to use the SSL. I know what is, so I know the differences between a self-certificate, and the one issued by a company. There are different kind of class. Because I don't want that my users/friends are alerted by the browser that the SSL certificate isn't trusted, I'm asking if there is some free trusted certificate for a non-domain web server (I use my static IP to let the user access the website). In case I bought a domain (it is very cheaper), can I have a free trusted certificate from someone ? Thank you.
Regarding SSL certificates for an IP address, see the linked SO thread: Is it possible to have SSL certificate for IP address, not domain name?
If you register a domain name for your site, then you can obtain a free SSL certificate from StartSSL (https://www.startssl.com/?app=1)
I have this web app that is served via https, and now it needs to use a websocket service that is served from another server. Chrome, Firefox and Internet Explorer complain right away that if the application is secure (https), then it is not allowed to connect to an insecure websocket service (ws:// URI). Strangely, Apple Safari doesn't complain so.
Well, fair enough, I assumed any globally trusted certificate would be fine to be installed at the websocket server side, to enable secure service (wss:// URI). However the company that maintains the socket server claims that they have to install there the very same certificate that secures my web application. I read in webs that the wss will not run with self-signed certificate, but nowhere that it must be the same certificate that the calling web site runs on.
Since we are talking sharing a certificate key file with 3rd party, I wanted to double check this. If my secure site runs at domain first.com, and the websocket server at IP address a.b.c.d, what kind of certificate should be installed on the websocket server to enable the communication? On one hand, that would be a kind of cross-site scripting, but perhaps the browser security model allows it, assuming the user knows what they want?
What I understand from above, the browser connects to your web application and is then redirected to the other server. If that be the case, then browser would complain about being redirected to unsecured site from a secured URL. The way forward actually depends on the domain of the server that the redirect is happening to, for example, if your main site has URL form www.mainsite.com and the target site has URL form abc.secondsite.com or an IP, the second server must have configured an SSL certificate that has been issued to either abc.secondsite.com of the IP i.e. the name of the host requested must match exactly with the SSL ceritficate that is provided by the secondsite.
The secondsite technically does not have to have the same certificate as your mainsite, it just have to be a certificate issued by a trusted source (like Verisign etc.).
On the other hand, if you have a wildcard subdomain certificate i.e. a certificate issues is valid for all the *.mainsite.com domains and the URL form of the secondsite is sub_domain.mainsite.com, then the same certificate can be used on both the servers.
Hope this helps.
thanks
Since we are talking sharing a certificate key file with 3rd party, I
wanted to double check this. If my secure site runs at domain
first.com, and the websocket server at IP address a.b.c.d, what kind
of certificate should be installed on the websocket server to enable
the communication? On one hand, that would be a kind of cross-site
scripting, but perhaps the browser security model allows it, assuming
the user knows what they want?
You cannot provide a certificate for an IP address. In order to use WSS:// you need to connect to a domain name, and have a valid certificate for that domain name. So you need a SSL certificate for the domain name of your WebSocket server.
As far as I know, it does not need to be the same than the one on the site. You can check by entering here: http://vtortola.github.io/ng-terminal-emulator/ and executing the command websocket wss://echo.websocket.org, you will connect to a WebSocket in websocket.org that echoes your inputs.
WebSockets are not constrained by the SOP (Same Origin Policy), you can connect anywhere, and the server is responsible of checking the HTTP request header "Origin" and accept or refuse the connection.
Is it possible to spoof or impersonate a server's IP?
So that clients wanting to connect to that Server's IP, would actually connect to the attacker's machine?
But the attacker would still be able to contact the actual server.
This is all TCP/IP based, no name resolution, and all machines are on the same network or the internet (No NAT-ing).
I am working on a networking application, and I would like to build in some authentication.
What I need to do is to authenticate the server by IP. In other words, I want to make sure that when I open a HTTPS URL to an IP Address, it will go to the machine that has that IP.
Other notes:
All communication would be over TLS, but certificates would be blindly accepted.
What I need to do is to authenticate the server by IP. In other words, I want to make sure that when I open a HTTPS URL to an IP Address, it will go to the machine that has that IP.
This is one of the features of HTTPS (SSL/TLS) - it can prevent a MITM attack and prevent the destination server from being impersonated.
Other notes: All communication would be over TLS, but certificates would be blindly accepted.
This is great, however you will need to stop certificates from being blindly accepted. You should check that the common name or subject of the certificate matches the server that you are expecting to make contact with. You should also check that the root certificate is one that you choose to trust (you could make your own root certificate that is trusted). This will prevent the server certificate being spoofed by an attacker as they will not be able to sign the certificate with the root certificate.
An alternative is certificate pinning. This will enable your application to only communicate with a pre-set list of trusted certificates that are either hard coded into your application, or that are otherwise inaccessible to outsiders on your application server.
Yes, if you can perform man-in-the-middle attack. Evil transparent proxy in your LAN can do it.
I have created my SSL certificate using Selssl7.exe on server1 but used Cn as Server2 and hosted the certificate on server2. I started to get a certificate error when browsing from linux firefox saying:
This certificate is invalid, the certificate is not trusted and is self signed, the certificate is only valid for server1
But when I browse the URL from Windows IE I just get the regular error saying that it's not trusted and I can easily add it to exceptions.
Can we use self-signed certificates generated on server1 on a different servers?
You can and you may but you are pretty much undermining each and every aspect of authenticity by doing so.
A self-signed certificate is generally a problem because other users will not know this certificate in advance. So their browser dutifully issues a warning. That's why you have to pay for TLS certificates that will be recognized - they are issued by CAs whose certificates are contained in the default trust store of your browser. CAs had to pay to "be part of the club", but otherwise, anyone can create certificates. It's just the matter of being recognized by default settings.
But you open another hole by reusing a certificate that was issued for a dedicated server on a different server. TLS certificates' subject distinguished names must match the host name of the server they are deployed on. This is mandated by the TLS spec because this is the only effective measure to prevent man-in-the-middle attacks when using TLS. After you open a TLS connection to a server, your code will check whether the host name that you are connected to matches the subject DN of the server's certificate that was sent. Only if it does you can be sure to be talking to the right server.
So, in conclusion, if you reuse a server certificate on a different host, then you are severely impacting the security of TLS. It's still possible, sure, but if you cripple security to this extent, then you are probably better off using plain HTTP in the first place.