(no subject)
Rick and I went to Master Taino's to have dinner at His place on His birthday -- the steak was quite tasty, just the right amount of garlic. MT's visiting boy from Holland, Ed was there still. And his slave David.
David has just been through A+ certification classes, and passed his exams -- for Networking and for Security as well. I was very interested to probe his mind about his experiences -- I would have thought those classes would have been more hands-on, but he said it was all textbook.
We got into details on two subjects... which lead me to conclude that while he remembers a lot of details correctly, he's still missing some of the more important pieces from the big conceptual puzzle.
TCP/IP - yes its used for http, but its so much more pervasive than that, and certainly Unix and Mac systems use it for their stuff. It is used for FTP, and just about everything, by every system. There do exist other transport/networking protocols... and he learned about them all, but he has some wrong ideas about where they are used and by which operating systems. I'm really don't know much about where they ARE used, but he was certainly matching them to situations that are actually TCP/IP. Further, when I researched telnet are pointed out to him that it is connecting to a TCP port, he claimed that was not an indication that TCP was being used. But the P is for Protocol, and a TCP port only understands TCP...
The second subject we talked about (actually the first) was SSL. I did not have all the details fresh enough in my mind, but David was saying that SSL does not have public keys. Now, I knew that SSL uses a PKI with both private and public keys. We were on the same page regarding PKIs -- that data encrypted with the private key could be decrypted by the public key. But he was thinking that the public key would change and must be sent every time... and that SSL didn't use public keys for some reason relating to the lack of security in that. But the way it works is that the public keys are sent ONCE, and are discussed by real human beings, who load each others public keys into their own systems -- after that any data a sender signs with their private key can be decrypted by the receiver with the public key, with assurance of identity of the sender.
I actually had fun talking about all this.... he certainly knew things that I didn't. I don't think he had as much fun... to him, its just work.
David has just been through A+ certification classes, and passed his exams -- for Networking and for Security as well. I was very interested to probe his mind about his experiences -- I would have thought those classes would have been more hands-on, but he said it was all textbook.
We got into details on two subjects... which lead me to conclude that while he remembers a lot of details correctly, he's still missing some of the more important pieces from the big conceptual puzzle.
TCP/IP - yes its used for http, but its so much more pervasive than that, and certainly Unix and Mac systems use it for their stuff. It is used for FTP, and just about everything, by every system. There do exist other transport/networking protocols... and he learned about them all, but he has some wrong ideas about where they are used and by which operating systems. I'm really don't know much about where they ARE used, but he was certainly matching them to situations that are actually TCP/IP. Further, when I researched telnet are pointed out to him that it is connecting to a TCP port, he claimed that was not an indication that TCP was being used. But the P is for Protocol, and a TCP port only understands TCP...
The second subject we talked about (actually the first) was SSL. I did not have all the details fresh enough in my mind, but David was saying that SSL does not have public keys. Now, I knew that SSL uses a PKI with both private and public keys. We were on the same page regarding PKIs -- that data encrypted with the private key could be decrypted by the public key. But he was thinking that the public key would change and must be sent every time... and that SSL didn't use public keys for some reason relating to the lack of security in that. But the way it works is that the public keys are sent ONCE, and are discussed by real human beings, who load each others public keys into their own systems -- after that any data a sender signs with their private key can be decrypted by the receiver with the public key, with assurance of identity of the sender.
I actually had fun talking about all this.... he certainly knew things that I didn't. I don't think he had as much fun... to him, its just work.