Understanding Internet Security - Implementing SSL/TLS Using Cryptography and PKI - page 2

chagrin, that RFC 2246 presumes a background in symmetric cryptography,
public-key cryptography, digital signature algorithms, and X.509 certifi cates.
It's unclear where to even begin. Although there are a handful of topics that
describe SSL and “Internet Security,” none are targeted at the technically inclined
reader who wants, or needs, to know the details.
A mantra among security professionals is that the average programmer
doesn't understand security and should not be trusted with it until he verses
himself in it. This is good, but ultimately unhelpful, advice. Where does one
begin? What the security professionals are really trying to tell you is that, as a
practitioner rather than a casual user, it's not enough to treat security as a black
box or a binary property; you need to know what the security is doing and how
it's doing it so that you know what you are and aren't protected against. This
topic was written for you — the professional programmer who understands the
basics of security but wants to uncover the details without reading thousands
of pages of dry technical specifi cations (only some of which are relevant).
This topic begins by examining sockets and socket programming in brief.
Afterward, it moves on to a detailed examination of cryptographic concepts
and fi nally applies them to SSL/TLS, the current standard for Internet security.
You examine what SSL/TLS does, what it doesn't do, and how it does it. After
completing this topic, you'll know exactly how and where SSL fi ts into an over-
all security strategy and you'll know what steps yet need to be taken, if any, to
achieve additional security.
What Are Secure Sockets?
The Internet is a packet-switching network. This means that, for two hosts to com-
municate, they must packetize their data and submit it to a router with the destina-
tion address prepended to each packet. The router then analyzes the destination
address and routes the packet either to the target host, or to a router that it
believes is closer to the target host. The Internet Protocol (IP), outlined in RFC
971, describes the standard for how this packetization is performed and how
addresses are attached to packets in headers.
A packet can and probably will pass through many routers between the sender
and the receiver. If the contents of the data in that packet are sensitive — a pass-
word, a credit card, a tax identifi cation number — the sender would probably
like to ensure that only the receiver can read the packet, rather than the packet
being readable by any router along the way. Even if the sender trusts the rout-
ers and their operators, routers can be compromised by malicious individuals,
called attackers in security terminology, and tricked into forwarding traffi c that's
meant for one destination to another, as shown in http://www.securesphere
.net/download/papers/dnsspoof.htm . If you'd like to get an idea just how many
different hosts a packet passes through between you and a server, you can use