Another question for the technically minded for discussion:

What is SSL in relation to the Internet?
Discuss a number of the services provided by this sub-system, especially
authentication, integrity, and privacy.
Are there any problems with the SSL concept and its implementations?

28 responses total.

        As I read up on SSL, (see OpenSSL, btw), I get the impression -
        which the true techs can verify or not, that:

        1) SSL is inert unless both sides *agree* to use it;
        2) SSL remains inert unless you have a paid-up "certificate"
            for the server;
        3) SSL servers are also obligated to pay a license-fee to the
            folks at RSA;
        4) The above certificate is federally filed, ergo "security" is
            mostly against snoopers of the "haxor" and "hacqueer" flavors.

        I 'spect marcus, ken, jazz, janc and the lot can add more.

Re: 2 - you can self-issue certificates, and if people trust your
assertion that you are who you say you are, then SSL works fine.
What you're paying for by getting a certificate from Verisign, etc,
is a third party vouching for you, that third party being trusted
by default by the browser.

The fact that the certificate is federally filed doesn't mean that
your transmissions can be read by the government, also.  The cert
is basically different layers of asymmetric encryption -- that is,
encryption that has two different keys, a public half and a private
half.  Messages encrypted with the public key can only be decrypted
by the private key, and vice versa.

To verify your certificate, which is basically just a block of data
encrypted by the certificate authority's private key, the software
uses the well-known public key of that CA to try to decrypt it.  If
your certificate is valid, the data is readable and you have proven
that you have a valid certificate that has been "stamped" by the
CA, which is the "root" of the trust tree, so to speak.  Your cert
has your hostname tied into it, so when it is decrypted, that hostname
can be compared to the hostname you're trying to talk to.

        oh, wow.. you can issue yer own certs?? fookin'-A..!

        Details as to how to do THAT (or where to find such) would be 
        marvy, man..

        The idea of a "central repository" for certs makes sense when
        surfing or doing "plastic-transactions" on ther web, but..
        Sheesh.. If you are simply concerned about point A-to-B security,
        that's great..!

        What about the payment to RSA?

But why should I allow my browser to accept your certificate?  Sure,
encryption is nice, but not when you can't trust the key.

I don't understand the details being discussed here, but I would like
to ask if they could apply to a problem I have been having in upgrading
Netscape 4.6.1 to Netscape 4.7, as described in the Internet cf, Item 88,
Resps 29ff. Another new factor is that when I last logged into my
on-line bank, I got a dialog that said my certificate had expired, and
that it was not their (the bank's) fault, but I should get an upgrade
for my browser. I could still use my online banking, but that dialog
just shows up every time. 

re 4:

        Examples: You want to be secure in passing around yer password
        when you log into Backtalk, Webparty or whatever.. Further, you 
        may be in a channel or conference you REALLY do not want some
        damned "haxor/hacqueer" snooping.

        SSL would also be applicable to email, telnet, etc, etc..

        If zero effort on the users part meant they could "grex" w/o
        a bit of chance some nimrod was peeking at packets, you'd
        consider it.

SSL does not, in my experience, apply to 'email, telnet, etc'; it 
applies *only* to the web.  SSH (Secure Shell) and Kerberised Telnet
offer the same advantages, but the (I don't think) they use SSL.

Rane, these certificates are set to expire every five years or so, to
encourage us all to keep up with the latest in encryption technology.
(Like a second-best army, old encryption software is a waste of money.)
The encryption works because both the browser and the server have
certificates.  The certificates built into earlier versions of
Netscape Navigator have now expired.  (Coincidentally, they expired on
or about December 31.)

Yes, you need to get a new (and it may as well be the most recent) version 
of your browser.  If you are going to do that, work hard to get the
'domestic' version; it uses longer (and therefore stronger) keys than
the export version.  (I find it works best to get them onto my office
machines and then transfer them to my home machines:  Netscape doesn't
like to admit that my dial-up connections are in the US.)

Re: 7 - SSL is a general-purpose protocol for secure exchange of key
information.  It's just that the web has seen the most widespread
deployment of it.  For instance, see http://www.ncsu.edu/imap/sslimap.html
for information about using SSL on an IMAP server.

Re: 4 - if you're just futzing around with your own stuff, why bother
with a certificate that everyone in the world will trust?

SSL certificates can be used with S/MIME for signed and encrypted e-mail.

By the way, SSL doesn't have to use cetificates.  The better way is to
establish a session key using Diffie-Hellman.  Part of the standard, this is
a better solution, unfortunately rarely used.

Except that generating a key pair must take a God-awful amount of time (this
is that prime number pair thingie, isn't it?) it should be possible to
generate key pairs on the fly, a new pair for each session, without either
party ever knowing any key. Just send to each other the public keys, store
the private ones somewhere in memory, and start over again each new connection
- for a brand new key pair. Tiny statistical universes, all different and
random.

Re #10: But if you don't use a certificate, how do you know that the
person who gives you a random new key is really the person you intended
to talk to?  We don't have dnssec yet...

Certificates aren't necessary - basic public key crptography wasn't designed
with them in mind, and a PKI is basically just a buzzword.  Very difficult
to manage, and often not needed (or used!).

Ok, how do you compose trust relationships without certificates?

Trust is an extremely difficult commodity, with or without certs.

Trust has a fairly well-defined and simple meaning in the cryptographic
community.  With kerberos, it's pretty easy to describe the trust
relationships, but this is, of course, using symmetric encryption, and
has significant limitations.  Asymmetric encryption can get around those
limitations, but there's a specific mechanism that is commonly used to
do this.  Do you have an alternative to that mechanism?  Are you arguing
that the mechanism itself is fundementally flawed?  Or are you arguing
that the mechanism isn't necessary in the real world?

Re #5: after decoding a particularly cryptic sign-in/register dialogue
on the Netscape site, I re-registered and got a new password to the
Netscape site. This also made the certificate message from my on-line
bank go away. I'm not sure I like Netscape fooling with my computer
that way...

Along the way, one is offered an option to elect some commercial
security process for $15/year. Called "Veri-True", or something like that?
What is that, and how does it fit into the scheme of things?

I think you're referring to VeriSign.  They are one of the various
"Certificate Authority" entited referenced in previous posts.  Their
public key is built in to the browers, and essentially if your
certificate is signed by Verisign, the browser automatically concludes
that you are who you say you are.

But I did not sign up with VeriSign. Does that mean I'm not who I am?
(Or, who am I then?)

We're getting several levels of "trust" and security confused, lads..

        1) The sort of "trust" between grex-users and grex have, wherein:
           We trust GREX but nothing between us; and, GREX trusts us, but
           only after a challenge/response cycle. NOTE: we called YOU..

        2) The sort of "trust" between a user and his browsing of the net:
           ie. damn-little, since nearly anything can reroute you wherever
           and all the while, some halfassed buffon is shoving java-crap
           up yer schnoz..

        3) The sorta' "trust" between a user and his incoming email..
           Perhaps benign; perhaps malignent.. perhaps from someone you
           know, perhaps unsolicited.. Here is where the "verisign" certs
           *MIGHT* matter to a user.. particularly in a biz-setting.

        For all intents and porpoises, #1 is where we started this: a
        deliberate, interactive, transactional setting.

re 19:
        I think you're missing some fundamental logic there.  If a then b does
not mean if b then a.  In other words, "if you have a Verisign key, you are
who you say you are," does not mean, "if you do not have a Verisign key, you
are not who you say you are."

Does that help? Hmmm..I think I would like to know, why bother with
VeriSign when browsers include free SSL stuff.

The usual importance of verisign etc., is not to determine who you are
(although admittedly this would be useful), but rather to determine if
the *vendor* you're sending your credit card number to is in fact who
*they* say they are.  The reason to update the certificates in your
browser is to get the most recent top level certificates from the CA's;
this is basically the list of "people" you trust to vouch for other
"people" (well, in this case, vendors.) This is actually a more
significant step than it sounds, because it's really the one place where
the trust model breaks down.  (How do you know if you aren't downloading
bogus top level certificates?)

None of the uses of the word "trust" in #20 have much to do with the
formal definition of "trust" used by cryptographers.  In the usual
formal security model favoured by cryptographers, Alice and Bob want to
exchange data; they may be able to trust their friend, Trent, to help
them do this, but they have to somehow dodge the efforts of the evil
Mallet, who can intercept and read all their packets, and can change,
delete, or even introduce new forged packets at will.  The kinds of
questions cryptographers are interested are things like, how can Alice
know she's talking to Bob (or Trent), and not Mallet? Can Mallet fool
Alice or Bob into giving him enough information to read (decode) all the
traffic between Alice & Bob?  &Etc.  It is in fact possible to get
privacy without authentication (diffie-hellman), and authentication
without privacy (digital signatures), and authentication need not be
mutual but only work in one way (Alice may know she's talking to Bob,
but Alice may be just another pretty face to Bob.) Trust, to a
cryptographer, might refer either to a previously exchanged shared
secret, the trust that is placed in Trent, or might refer to some form
of authentication (I know this data came from Bob and not from anyone
else).  None of these notions of trust necessarily has to do anything
with the ordinary english meanings of the word; Bob is not necessarily a
bank, and it might not be safe to trust Bob with a loaded shotgun, or a
glass of vodka and an expensive sports car, or even your wallet.  In
some cases, Bob might even be a computer program and not a real human
being at all, in which case Bob might have about the intelligence of a
smart cockroach and not really understand concepts like "Vodka" or
"Trust" the latter of which, after all, is pretty abstract.

I wasn't commenting for cryptographers.

It's sort of like a drivers' license.  I hand someone my license, and
they observe all the pretty spangles and holograms on it, feel its
weight and texture, and the magnetic stripe on back, and trust that
based on these features it was officially issued by an agent of the
government of California.

Next, they note the photograph on the card resembles me, and note my
name and address, and through their trust in the procedures used by
the California DMV come to the conclusion that they can trust that
I am, in fact, who I say I am, since it matches what's printed on the
drivers license card.

A Verisign certificate is like this - my broser trusts Verisign and
the procedures they employ for identifying people to whom they issue
certificates.  The cryptographic "signature" of Verisign on the
certificate is similar to the spangles and holograms on my license.
The contents of the certificate, which assert an identity, are like
the name and address on a license, and much like a license can't be
altered without fouling up the holograms, these contents can't be
altered without invalidating the signature.

Wow, CA driver's licenses have holograms?  And here I've still got a
typed-and-laminated thing.  (Haven't had to renew in person since they
switched to the new "credit card" type plastic licenses, here;  I got lazy
and renewed by mail last time.)

Linked to the cyberpunk conference.  Your conference to discuss computer
security issues, the ethics of hacking/cracking, etc.

Back on the subject of RSA and licensing, you do have to pay licence fees to
RSA if you're based in the US. From what I understand, you're basically in
the clear in the rest of the world. Check out the Apache-SSL website - they
give some details...
Happily, the RSA patent expires August 20th! Woo!
(Next question is, will RSA try to sue people who call RSA encryption RSA
encryption.. They sent out a letter a while ago saying that they'd prefer it
be called something else. I'm in favour of rearranging the letters, and adding
the word "Encryption" to the end. Then people can label their products "ARSE
enabled")
That was too easy.

Response not possible - You must register and login before posting.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss