I dont know much how it works, but i understand that the first packet transmitted is not encrypted otherwise how would my pc know how to encrypt sent and decrypt received data, right?
The first packet is indeed not encrypted, but it also doesn't transmit HTTP data yet – it's a key exchange packet. At the start of every connection, TLS uses a key-exchange algorithm to have both sides generate the same encryption key without actually transmitting it to each other. After key exchange is finished, both systems now have an encryption key that a passive attacker (who only monitors your traffic) has no way of knowing. (The Wikipedia article on Diffie-Hellman key exchange illustrates how that works.)
(There are other key exchange mechanisms besides DH, such as having one side send an RSA-encrypted key to the other, but those are mostly obsolete – TLS and SSH always use DH now.)
You're right that an active attacker could intercept and replace those key-exchange packets – but that's what HTTPS (TLS) certificates are meant to prevent. The server responds with its own DH parameters plus its TLS certificate, and it signs all of the key-exchange parameters using the certificate's private key. (This also includes the first packet that was received from the client, to ensure that what the client sent is exactly what the server received.)
If the signature check succeeds, the client knows that 1) it's talking to a server that has been issued the certificate (anyone else wouldn't have the private key), 2) the server's reply hasn't been replaced by an attacker (who wouldn't be able to replace the signature), 3) the client's initial packet hasn't been replaced by the attacker either (as its data as seen by the server was included in what's being signed).
would a key, at least not received at the same time the https connection begins, and from another site, be the only safer way? Being the best getting this key using at least another ip? Or may be get the key thru mobile and use another wired connection to login?
For HTTPS (TLS in general), that's usually not required; the server's certificate is used to prove that the key exchange wasn't tampered with. You already have a third party – the CA (certification authority) that issued the certificate to the server – verifying its domain name during issuance, often indeed using multiple connections; as long as you trust (all the) CAs to do it properly, you don't need additional verification.
(Of course, you still need to get at least the CA's "root" certificate in a safe way – which is why they're included with your OS, and hopefully you got the OS in a safe way.)
But some other protocols such as SSH don't typically use CAs, in which case you do need to take similar steps yourself. SSH also uses key-exchange in nearly the same way as TLS, but instead you're asked to manually check the server's certificate during the initial connection (which the client remembers for later), and that is often done by using a "more secure" network for that first connection... or by publishing the certificate fingerprints over HTTPS.
