The initial exchange of public keys is over an insecure channel. Once both parties have the other party's public key, they can then use asymmetric crypto to agree on a symmetric key. After that, all communication is symmetrically encrypted. But notice that this depends on the initial exchange of public keys over an insecure connection. How do you know whether a third party hasn't intercepted the public key of one of the parties, substituted it's own, and subsequently forwarded messages back and forth between the two parties?
One solution is for the two legitimate parties to know each other's public keys (or the hash of each other's public keys) in advance. That's more secure, but unusual in 2018.
Another solution is for both parties to trust a third party entity, such as a certificate authority. Browsers and operating systems come prepackaged with a substantial quantity of trusted certificate authorities. A very substantial quantity. And those certificate authorities are usually businesses -- commercial enterprises with a physical presence and offices and bank accounts -- operating under the good graces of the governments that have pertinent jurisdiction over them. If such a government were to force a root certificate authority to issue a bogus intermediate certificate to the government, then that certificate would then be trusted by any Web browser that already trusted the root certificate authority. And as I pointed out, there are a LOT of trusted root certificate authorities in your browser and/or in your operating system. Each one of them is vulnerable to government-imposed coercion (or potentially even organized crime, depending on its relative impunity in that country). A compromise like this has actually happened, notably in 2011, to a cert authority named DigiNotar. This led to massive security breaches at the nation-state level.
Lastly, there is a solution of having a smaller version of the certificate authority system comprised of circles of trust, entities that are commonly recognized by communicating parties as trustworthy but deliberately selected in advance and not installed in the browser by default. Public keys could then be signed by a mutually trusted entity before they're exchanged via Diffie Hellman exchange.
The challenge is to exchange those public keys reliably before any subsequent encrypted communication occurs. Diffie Hellman is NOT a panacea.