This is a standard approach, called a hybrid cryptosystem. Symmetric cryptography and asymmetric cryptography each have their strong and weak points. In particular:
- Asymmetric cryptography allows anyone to encrypt messages that only one participant will be able to decrypt, and allows anyone to verify messages that only one participant can have signed.
- Symmetric cryptography is a lot faster than asymmetric cryptography. Really, a lot.
Security isn't really a concern in the choice between symmetric and asymmetric cryptography. Asymmetric cryptography solves problems that symmetric cryptography cannot; for everything else, symmetric cryptography is used, because it's so much faster.
(As a consequence of being faster, symmetric cryptography does tend to have a higher security margin: common key sizes — 128-bit AES — are large enough that barring a completely novel mathematical breakthrough, all the computers currently existing on earth working for as long as the universe has existed would only have a tiny chance of breaking the encryption. Asymmetric cryptography runs on smaller margins due to its poor performance and there are occasional mathematical improvements in cracking methods that make commonly used key sizes ok for a few years but not necessarily for a few decades. But this is a secondary concern compared to the capabilities/performance alternative.)
Hybrid cryptosystems resolve the dilemma by using asymmetric cryptography only where it's needed:
- To verify the signature of a message, the message is hashed, and asymmetric cryptography is used only on the hash, not directly on the variable-length message.
- To encrypt some data, a symmetric session key is generated. Asymmetric cryptography is used to share this symmetric key between the participants (the client and the server). The “real” data is encrypted and authenticated using this symmetric key.
In HTTPS as it is commonly used on the web, the server has a public key, but the client doesn't — any browser can contact the server, the server doesn't care who the client is. (Client-side certificates are used where it makes sense.) A very high-level and incomplete view of an HTTPS session establishment is:
- The server sends its certificate to the client. The certificate contains the public key of the server, and a signature of that public key by a certificate authority. The client verifies that the certificate authority is a known one (browsers ship with a list of certificate authorities' public keys).
- The client and the server arrange to choose a symmetric key, in such a way that an attacker will not be able to reconstruct the key merely by inspecting the traffic or even by modifying it (or at least an active attacker will be detected and the client or the server will then abort the session). A Diffie-Hellman key exchange plus a signature by the server (to let the client verify that the exchange was conducted with the server, and not with a man-in-the-middle attacker) is one possibility to generate the symmetric key. It's also possible to rely solely on the server's private key (at the expense of not ensuring forward secrecy).
- All subsequent communication uses that symmetric key.
Note that I made a lot of simplifications above. For more details, read: