https: what can go wrong if the certificate validation step perfomed by browser was eliminated?

In https protocol, the browser validates that the certificate presented by the server (for e.g. https://paypal.com) by checking the certificate is signed by a valid CA. Once this trust is established, the whole asymmetric encryption kicks in.

I understand the second part (asymmetric encryption, establishing secret key) well. However, I am not able to understand the need for the first part. Why does the server need to identify itself ?

Afaik, the dns registries will point paypal.com to the right IP addresses. So it is not like a hacker could manipulate the dns so that paypal.com points to his servers. Even if he does that, he could present another certificate that has been signed off by a CA.

I am looking for some examples of what can go wrong if the server identification step was eliminated?

Please do following:

1. Download an attack proxy like Burp or OWASP ZAP.
2. Turn it on, proxy your traffic from the browser. Accept the invalid certificate.
3. Play with manipulating the traffic with the proxy. Override the contend. Delete the content. Put malicious links there. Whatever.
4. Observe your browser.

See, it's not the paypal.com content any more. It's your own you see and there's still paypal.com standing in the browsers URL.

All kinds of MitM (Man-in-the-Middle) attacks are possible this way.

By the way, do you think your DNS calls are authenticated?

How about ARP poisoning (anyone in your local network can do that)? This is no rocket science, 10 year olds can perform such attacks.