17 internautes sur 23 ont trouvé ce commentaire utile
- Publié sur Amazon.com
I know this book got a lot of positive reviews, but the readers that are NEW to this subject and networking in general, have nothing to compare it to (the truth). Readers that KNEW the stuff before (See the first 3 star review) can see that the authors and TE have no clue about networking, security, or hacking. Furthermore, they have not kept up with anything and have tons of outdated and obsolete info.
I started reading, and had to stop around Chapter 5, since it was clear the authors and TE have pulled the wool over the eyes of newbies with their complete lack of truth and relevancy. This is like a scam, how so many people fell for this miserably incorrect book.
p2 - "Although authentication (using passwords, for example) is by far the most common method used to enforce confidentiality, numerous other options are available to ensure confidentiality, including options such as encryption, biometrics, and smart cards."
What doesn't make sense: Authentication can be done with something you know (password), something you have (smart card), and something you are (biometrics). Saying that Authentication is a different method than biometrics and smart cards is illogical. I know the parenthesis references passwords, but that's as you say, just an example of authentication. Biometrics IS authentication with something you are. Smart Cards are used for AUTHENTICATION, as something you have.
p15 - There were 4 original nodes on Oct 29, 1969, not 3, as the book states.
p40 - CAs do NOT create public/private key pairs, as the book claims. Here's Verisign's official policy:
NOTE: To generate a CSR, you will need to create a key pair for your server. These two items are a digital certificate key pair and cannot be separated. If you lose your public/private key file or your password and generate a new one, your SSL Certificate will no longer match. You will have to request a new SSL Certificate and may be charged.
p43 - Digital certificates from CAs are NOT encrypted, as the book claims! The way the CA is verified is through a digital signature hash, which is part of the actual certificate. If digital certificates were encrypted, there would be NO need for a digital signature. Furthermore, "digital signature could be not be verified" or "the certificate is not trusted" messages are seen in browsers. No one has ever seen a "cannot decrypt digital certificate." That's just illogical! Furthermore, you fail to mention that the browsers have the root CA certificates, which are used to verify the CA's signature. The certificate ITSELF is NOT encrypted, but rather the public key + digital signature hash on the certificate itself helps encrypt data.
p43 - student's heads should be students' heads (plural possessive)
p45 - PPTP is "widely used by VPNs"??? PPTP has been OBSOLETE for many years now due to L2TP and nowadays IPsec!
The SSL diagram on p45 is pitiful, at best. You fail to stress that the session key is encrypted with the server's public key, and then decrypted by the server's private key. From that point forward, symmetric encryption is used. Now, the client and server are using symmetric encryption, which is (literally) one million times quicker than asymmetric encryption, and the key was transmitted securely. That's the best of both worlds! SSL/TLS uses asymmetric encryption JUST for the exchange of the symmetric session key. The data going back and forth between client and server is encrypted and decrypted with the symmetric session key. Instead of that you chose to focus on finished messages with hashes??? Furthermore - They're encrypted, not hashed. Not the same thing!!
p46 - "...chosen cipher attack, where the same process is followed (statistical analysis without a plaintext version for comparisons), but it's only for portions of gained ciphertext."
A chosen-ciphertext attack (CCA) is an attack model for cryptanalysis in which the cryptanalyst gathers information, at least in part, by choosing a ciphertext and obtaining its decryption under an unknown key. In the attack, an adversary has a chance to enter one or more known ciphertexts into the system and obtain the resulting plaintexts. From these pieces of information the adversary can attempt to recover the hidden secret key used for decryption.
It seems you missed what the word "chosen" implies (You wrote that a chosen cipher attack is "without a plaintext version," when in reality, not only is there a plaintext version, it's a function of the ciphertext CHOSEN by the attacker!"
p47 - It's "John the Ripper," not "John and Ripper."
p47-48 - "Non-repudiation is the means by which a recipient can ensure the identity of the sender and that neither party can deny having sent or received the message." NR has NOTHING to do with denying a message was received, just sent.
Here's something encrypted with my private key. I want you to decrypt it with my public key. Wait you didn't receive it???? You must have, since I sent it, haha.
p48 - It's SHA-2, not SHA2. You have it correct earlier in the book, and you even wrote SHA-1 (with the dash in the same paragraph).
Oh yeah, in the Acknowledgements, you call Technical Editor Brad Horton "one of the best." Based on the above, that's clearly a mistake too.
Should I even continue to Chapter 3?
Out of morbid curiosity, I kept reading. More of the same illogical, incorrect, and mistaken information:
p62 - DNS stands for Domain Name System, NOT Domain Name Service
p66 - "..a choice between regular and unleaded gas" Huh? regular gas is unleaded gas!
p69 - output messed up
First read this from p87. By itself, there's nothing wrong with it:
p87 - "As a matter of fact, many administrators will disable ping responses on many network systems and devices, and will configure firewalls to block them."
But now read this from p88:
p88 - "Pay particular attention to Type 3 messages and the associated code, especially Code 13, which lets you know a poorly configured firewall is preventing the delivery of ICMP packets."
So on p87, it's a good thing that administrators do, and on p88, it's a stupid thing that administrators do.
p91 - If UDP is used, the layer 4 PDU is called datagram, not segment. Segment is specifically a term for TCP.
p91 - FTP datagram - Wrong. FTP uses TCP, so it would be a segment.
p93 - No netstat????
p94 - "...the sender can simple fire as many segments as it wants..." No! If UDP is the protocol, it's NOT called a segment. That's just TCP.
p95 - "UDP, as you can tell from the segment structure...." For someone who stressed networking fundamentals at the beginning of this book, continuously calling UDP a segment is really embarrassing.
p104 - "If you'd like to try a different protocol number, it follows the -pT switch." Wrong. Port numbers go after the -pT switch, NOT protocol numbers (TCP = 6, for example).
p109 - "The SAM database holds (in encrypted format, of course) all the local passwords" Wrong! It holds a hash of the passwords, which is not the same as encrypted, since hashes are one-way. p116 has this mistake too. Encryption is NOT the same as hashing.
p110 - TCP packets should be TCP segments. It's IP packets. Packets are the Layer 3 PDU.
p125 - In 1998 the TOS field in an IP packet was renamed DSCP and completely changed!!! Way to keep up!
p126 - "...if the IP address of the packet being sent is not inside the same subnet, the router will usually respond with its MAC address. Why? Because the router knows it will be the one to forward the packet along the way."
WRONG WRONG WRONG WRONG WRONG. This shows a real lack of any networking knowledge!!!!
The router will respond because the ARP Request is asking "Will the person will this IP address (the router's in this case) please send me your MAC address. That's why! The host knows to ask that IP address for its corresponding MAC address because the host routing table tells it so. The router has no idea what the destination network is when the ARP request comes in! The ARP just says "I need the MAC address that corresponds to this IP address."
p128 - Most NICs have, or will accept, drivers that support promiscuous mode.... WinPcap is an example.... and is used by a lot of sniffers on Windows machine NICs." OH MY GOSH. WHAT PLANET ARE YOU ON? Most NICs can NOT do promiscuous sniffing through Windows. Wireshark has tons and tons of info on this on their website! There are drivers close to $1000 that you can buy to allow this, but it's much easier to just run Backtrack and put your NIC into Monitor Mode.
p129 - CSMA/CD is disabled when the switch and host NIC run in full duplex mode, since collisions are completely eliminated. Or did you miss that too?
p130 - "turn off promiscuous mode - you'll catch more frames this way...." First of all, most of the time when you put a check in that box it DOESN'T do anything (see above). Secondly, you think that if you're sniffing everything and anything you'll get LESS results than if you're sniffing just your traffic???? Whoa.
p145 - The RFC 1918 private class C range is 192.168.0-255.0, Mr Editor. You did correctly identify Class B's range as 172.16-31.0.0, so why not Class C as well?
P177 - Randomly skimming ahead (lots more mistakes between p145 and p177), I came across this gem:
"Red Hat is one of the better known and most prevalent Linux distros."
Guess you "experts" missed this:
Red Hat Linux, assembled by the company Red Hat, was a popular Linux based operating system until its discontinuation in 2004.
Red Hat is a COMPANY. Red Hat Linux (which was referenced by the book) was discontinued in 2004. Red Hat discontinued the Red Hat Linux line in favor of Red Hat Enterprise Linux (RHEL) for enterprise environments. Red Hat ENTERPRISE Linux is a non-free version, which hardly qualifies as a "better known and prevalent distros," in the context of what the author was talking about (Ubuntu and other free ones).
That's it, I can't read anymore....