Wilfred L. Guerin wrote:
Even worse, you read FCC Part 15 rules and ask "why would I WANT it to ACCEPT INTERFERENCE??"
You may want to read http://www.proz.com/kudoz/english/electronics_elect_eng/1105076-device_must_accept_any_interference_received.html for information on what "accept interference" means. Basically, it means that it must not explode or melt down - not that it must take orders from arbitrary other people and send them your credit card numbers.
> This httpS message sends the wire negotiated encryption key over the > wire WITH the "encrypted" data. Do you frequently write the lock > combination on the safe or tape the key to the lock when it is left in > hostile environments?I think you really, really need to go learn more about cryptography and the https protocol, as there's no point where what you described actually happens. The closest is when the client sends a chunk of random data to the server, which they both use to generate the encryption keys . . . and this only happens once it's already encrypted by the server's public key, meaning nobody besides the server can read it.
As a side note, HTTPS is basically HTTP wrapped in an SSL/TLS session . . . and guess what Tor uses? If it's as insecure as you claim, Tor is pretty hilariously broken.
-Ben