Can HTTPS server configured without a server certificate?
I have noticed that, a HTTPS connection can be set up with the server configured to use a certificate, and when additional security is required, the server can ask the client to provide a client certificate, validate it and set up connection.
It seems that, if we ask all clients to provide their certificates, which contains public keys and corresponding signatures, the secure connection should also able to be established. The server just validates the signatures, then encrypts the data being send using client's public key. If knowledge of the identity of clients is more important than that of the server, the server certificate is of no use here.
So is it supported in HTTPS protocol, that the server provides no certificates but ask for client certificates, and then establish HTTPS connection?
HTTPS is HTTP-within-SSL. SSL is a tunnel protocol: it works over an existing bidirectional stream for data, and provides a bidirectional stream for data. The two parties involved in SSL are the client and the server, which are two roles within the SSL protocol; it is not required that these roles map to the notions of "client" and "server" of the underlying transport protocol.
For instance, a setup can be imagined, in which the client system (C) initiates a TCP connection to the server (S), and then the server initiates a SSL handshake, acting as the SSL client (i.e. sending the
ClientHellomessage, instead of waiting for an incoming
ClientHello). This reverses the roles of both machines, and also the security guarantees: the machine S will have a good idea of the identity of the connected client C, but the client C will not be sure of what server S it is talking to (an attacker could have intercepted and redirected the communication). Depending on the context, this may or may not be appropriate.
However, this departs from HTTPS, in which the TCP client is also the SSL client, and that client expects the server to show a certificate, which the client will validate against its known, trusted CA, and which contains the expected server name (as extracted from the URL, see section 3.1). Correspondingly, existing clients (Web browser) do not support reversal of SSL roles. If your situation calls for using browsers, then you must, of course, use only the functionality available in browsers.
SSL does support a few certificate-less cipher suites. The "DH_anon" cipher suites are deemed weak, because they imply no authentication at all (thus, Man-in-the-Middle attacks are possible). The PSK cipher suites imply mutual authentication of both client and server with regards to a shared secret. When the shared secret is of low entropy (say, it is a password), SRP cipher suites are better.
There again, these cipher suites are not (yet) available in mainstream browsers (although some people are working on it). They require a shared secret (key or password), a condition which may or may not be easy to achieve in your specific context.
If knowledge of the server identity is unimportant, then you can give the server a self-signed certificate, along with instructions for clients on how to make their browser accept the server certificate without cringing too loudly (see this question as a starting point). This will map to "normal SSL", which has two benefits:
- Existing browsers support that.
- When the server presents a certificate, however bogus, it is then allowed to ask, in return, for a client certificate, yielding the kind of authentication that you are looking for. And Web browsers do support client certificates for SSL.
Note that the self-signed certificate contains the server public key. Though this public key won't be validated, it will still be used to power the key exchange, so you must use an appropriate key type and length (say, RSA 2048). Alternatively, use one of the "DHE" cipher suites, in which case the server public key is used only for signatures, not to actually protect the data, so (in your specific case), its size and secrecy becomes unimportant.
No. According to the specifications of HTTPS, a certificate is needed as it's the way a server identifies itself to the client. The certificate doesn't need to be valid, i.e. the certificate doesn't have to be issued and signed by a CA that the browser trusts by default.
HTTPS (HTTP over TLS) was built on the idea that we need to make sure we're actually connected to the same web server to which we're trying to connect. In fact, you'll see that many web server software don't even have the support for two-way HTTPS authentication.
Of course, there are exceptions (anonymous cipher suites, pre-shared keys, etc.) but they all come with their own problems. For example, Mozilla doesn't support anonymous cipher suites in their products. Chrome recently went the same route as well. Pre-shared keys have the regular deployment issues which really takes convenience of public-key encryption.
Bottom line is: You need a server certificate for HTTPS.
No. The moment you start the TLS exchange you need to provide your own public key.
Besides, this would never work. There pretty much aren't any MITM attacks that are only "passive", an attacker can modify the data as long as s/he is able to sniff it.
And the attacker can simply pretend to be the client by intercepting the connection before TLS starts (in vanilla HTTPS, this doesn't work as the trust of the fake webserver cert is cannot be established), and present his own cert as the client cert.
Also, RSA requires two keys. You need to encrypt text with your private key and the client's public key. A public key comes hand in hand with a cert, so you will need one.
You have to have a certificate, but it can be one you make yourself.
SSL (which is what HTTPS provides) requires a certificate for secure communication because that is the foundation of the encryption and what is used to authenticate that the server is who they claim to be.
If you make a certificate yourself, your users won't have any reason to trust the certificate unless they know it to be accurate already (since it doesn't have any independent verification of your identity) but it will provide the encryption just fine and will confirm to someone connecting for a second time that they are connecting to the same server as before.
just a short ammendment: you mix server-certs, which are needed to provide HTTP_S_ - services, and client-certs that are used to authenticate a client.
Although called Certs, Client-Cert have nothing to do with Encryption; they are just about to Authenticate the Client against a Service. Client-Certs are generated using some kind of PKI, where an authority with a ROOT-Cert ius ablke to generate and Sign CLient-Certs.
Apache can perform Authentication via Client-Certs, as well as VPN