SSL on networks and websites?

Can anyone tell me what it does? What is its intended purpose?

Does it,

1). Just ensure you are connected to a trusted computer? or does it

2). Also add encryption to the connection and not allow anyone to see whats
going on?

I have been advised to add SSL onto my server, but I'm not sure what the
purpose would acheive...

When someone goes onto a SSL website, we all know that we see a padlock
appear in the bottom of the browser, but can someone explain what is
actually happening in the background, when we are connected to a secure SSL
site? Thats the bit I am wanting to know more about.... For instance, I am
wanting to make more secure, private documents on my server, which is logged
into by company employees. If we went the SSL route, would this be
achieved? Furthermore, does an SSL session allow the ISP to watch whats
being transferred?

Just a few questions I would like to get answers to...

Many Thanks

Justin Tyme wrote:
> Can anyone tell me what it does? What is its intended purpose?
>
> Does it,
>
> 1). Just ensure you are connected to a trusted computer? or does it
>
> 2). Also add encryption to the connection and not allow anyone to see
> whats going on?

Both of them.
The traffic is encrypted and you can look at the certificate that the
webserver is presenting to verify that you have connected to who you think
you have
--
Alex

Hermes: "We can't afford that! Especially not Zoidberg!"
Zoidberg: "They took away my credit cards!"

www.drzoidberg.co.uk
www.sffh.co.uk
www.ebayfaq.co.uk

"Dr Zoidberg" <AlexNOOOOO!!!!!@drzoidberg.co.uk> wrote in message
news:(E-Mail Removed)...
> Justin Tyme wrote:
>> Can anyone tell me what it does? What is its intended purpose?
>>
>> Does it,
>>
>> 1). Just ensure you are connected to a trusted computer? or does it
>>
>> 2). Also add encryption to the connection and not allow anyone to see
>> whats going on?
>
> Both of them.
> The traffic is encrypted and you can look at the certificate that the
> webserver is presenting to verify that you have connected to who you think
> you have
> --
> Alex
>

So would it be the case that no-one (including the ISP would be able to
access or tell what files were being transfered? Not that I'm that obsessed
with security, or bothered about the ISP seeing my files, but I just want to
get a feel of how secure SSL might be when in use. And finally, how could I
confirm that SSL is actually working, other than seeing the padlock in IE?
Is there any software that can monitor the data and tell the difference
between encrypted and unencrypted data?

Thanks

On 3 May 2005 00:07, "Justin Tyme" wrote:

>Is there any software that can monitor the data and tell the difference
>between encrypted and unencrypted data?

I haven't used any since the days of 'thick ethernet' (a thick orange coax
cable, for 10 Mbps ethernet, which was in place where I worked in the late
80s) but searching for 'packet sniffer' / 'promiscuous mode' (I kid you not)
should find you more info. I have not looked for apps which run on Windows,
but you might find some which are shareware. You should be able to filter
the traffic, so you might (a) select the traffic coming to/from your local
PC [to collect some unencrypted packets] then (b) make a connection to
the protected website, and see the padlock, and (c) compare some further
packets and note the contents are far from useful :-)

You are probably best running the sniffer on a separate PC, but one minor
problem might be that with modern kit, you probably have each system on a
router, which will separate the traffic. IE incoming traffic from an ISP
will be separated and sent down single connections to the router, rather
than being available to all PCs. If that's the case, you'd need a hub,
so your sniffer could see all traffic on the LAN.

The sniffer won't care whether the data is encrypted or not, it will just
log and display whatever it 'hears' coming off the LAN... down to you to
interpret whether it is encrypted or not. In an ISP/government logging
situation, yes, they may easily be able to tell that the data was being
encrypted, but much of the time, I guess there's so much random binary
'junk'[*] flying about there'd be no way anyone would actively seek
such, unless someone was being monitored (eg a suspected terrorist) in
which case it would all be logged.[*] junk as in something different
to easily identified 'plain text' - in my case audio or video streams!

Compare having a receptionist shouting messages to individuals in their
rooms using individual pipes (a router) where person in room 101 does not
hear anything for someone in room 115, compared with (hub) shouting all the
messages down the corridor, so everyone can hear (but normally only take any
notice of messages with their room number at the start). HTH. Peter M.

On 2 May 2005 14:00, "Justin Tyme" wrote:

>I am wanting to make more secure, private documents on my server, which is
>logged into by company employees.

Unless they can connect from 'anywhere' not just from their offices/homes,
you could add restrictions by IP address (so long as they used ISP services
with fixed not dynamic), and password-protect the directory/directories that
hold the documents... If each user has their own user/pass combination, the
user can be identified from the raw web logs, access can be limited to a sub-
set of directories, and if the user/pass is used from a variety of IPs then
you could investigate the IPs which were used, in case the details weren't
being kept secure [eg employee made an arrangement with a competitor for
cash, allowing competitor to view/download files]. User/Pass would work
even if you were unable to restrict by IP address (eg because of employees
connecting in from client sites, etc, etc so unable to have fixed IP).


--
runbox.com - 1000 MB of mail storage and 100 MB for files...
30 day free trial... <http://web.vfm-deals.com/runbox/>

> So would it be the case that no-one (including the ISP would be able to
> access or tell what files were being transfered?

Exactly, although, your isp could obviously just look at the logs to see
what was being transfered. They couldn't, however, see the actual data, or
rather, identify the data being transfered.

> Not that I'm that obsessed with security, or bothered about the ISP
seeing my files
You should be.

>And finally, how could I
> confirm that SSL is actually working, other than seeing the padlock in IE?
> Is there any software that can monitor the data and tell the difference
> between encrypted and unencrypted data?

You can indeed. You need some packet sniffing software which will show every
single packet that your computer sends or recieves. I can't think of any
windows client off hand but I'm sure google will find a few. Windows being
Windows though, you'll probably have to hand some cash over at some point
;o)

The difference is, without wanted to sound obvious, if it's not encrypted,
you can read it. If it is, you can't.

HTH,

treefrog

Look for "Ethereal" - http://www.ethereal.org is a good starting place.
This is sniffer software that runs on a PC.

Just a heads-up. SSL's certificates work as follows...

1. I've been offered a certificate that says "Mr X vouched me"
2. Mr X has a certificate that says "Mr Y vouched me"
3. Mr Y has a certificate that says "Mr Z vouched for me"

Oh, Mr Z, you say. I know and trust him so if he vouched for Mr Y, I trust
them, and if Mr Y vouches for Mr X then I trust them too.

But there are also such things as "self-signed" certificates and also those
popups which you will, sooner or later, get saying either "umm, don't know
who created this certificate" or "this certificate looks valid but its
expired". Your choice as to whether to accept these!

Finally, seeing https://a_website.com (note the "s" in https) is normally a
good sign. You would expect to see the padlock too but the "s" is for
"secure".

Paul DS.

"Paul D.Smith" <(E-Mail Removed)> wrote in message
news:42787cc1$0$301$(E-Mail Removed) t...
> Look for "Ethereal" - http://www.ethereal.org is a good starting place.
> This is sniffer software that runs on a PC.
>
> Just a heads-up. SSL's certificates work as follows...
>
> 1. I've been offered a certificate that says "Mr X vouched me"
> 2. Mr X has a certificate that says "Mr Y vouched me"
> 3. Mr Y has a certificate that says "Mr Z vouched for me"
>
> Oh, Mr Z, you say. I know and trust him so if he vouched for Mr Y, I
> trust
> them, and if Mr Y vouches for Mr X then I trust them too.
>
> But there are also such things as "self-signed" certificates and also
> those
> popups which you will, sooner or later, get saying either "umm, don't know
> who created this certificate" or "this certificate looks valid but its
> expired". Your choice as to whether to accept these!
>
> Finally, seeing https://a_website.com (note the "s" in https) is normally
> a
> good sign. You would expect to see the padlock too but the "s" is for
> "secure".
>
> Paul DS.
>

Oh. I wanted to use SSL to make sure no documents that were being transfered
could be read or made sense of, if this SSL is just to confirm that the site
is genuine, then it is pointless for my cause. The only people who use our
site are the people have already been using it for a year or more. They
already know its a valid site and have password and username to log-in. It
was the log-in process I was trying to make more secure with SSL, and ensure
that any files transfered couldn't be made sense of.

Justin,

I've confused you with too much detail I'm afraid. SSL does both, and, if
you think about it, needs to do both. There is no point exchanging
encrypted data with someone unless you are really sure that they are who
they say they are (but see below). Otherwise, you might just as well
broadcast "here's my bank account" all over the internet :-).

What will almost certainly happen is that your site will have a certificate,
which your user's will trust, but you will get given back a generic "I'm
Internet Explorer" type certificate which you don't really trust but allows
the user to send their account details encrypted and _then_ you trust them.

You've reached the limit of my knowledge here but I would strongly recommend
that you get some more expert help with this task. It's quite easy to get
SSL to work, but looks can be deceptive as there are better, or worse,
levels of encryption and therefore security. For example, one of the
absolutely valid methods is the "identity" encrpytion - which does nothing!
If you have some need for security, get some expert help and carefully work
through what level of security etc. etc.

Paul DS.

"Justin Tyme" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> "Paul D.Smith" <(E-Mail Removed)> wrote in message
> news:42787cc1$0$301$(E-Mail Removed) t...
> > Look for "Ethereal" - http://www.ethereal.org is a good starting place.
> > This is sniffer software that runs on a PC.
> >
> > Just a heads-up. SSL's certificates work as follows...
> >
> > 1. I've been offered a certificate that says "Mr X vouched me"
> > 2. Mr X has a certificate that says "Mr Y vouched me"
> > 3. Mr Y has a certificate that says "Mr Z vouched for me"
> >
> > Oh, Mr Z, you say. I know and trust him so if he vouched for Mr Y, I
> > trust
> > them, and if Mr Y vouches for Mr X then I trust them too.
> >
> > But there are also such things as "self-signed" certificates and also
> > those
> > popups which you will, sooner or later, get saying either "umm, don't
know
> > who created this certificate" or "this certificate looks valid but its
> > expired". Your choice as to whether to accept these!
> >
> > Finally, seeing https://a_website.com (note the "s" in https) is
normally
> > a
> > good sign. You would expect to see the padlock too but the "s" is for
> > "secure".
> >
> > Paul DS.
> >
>
> Oh. I wanted to use SSL to make sure no documents that were being
transfered
> could be read or made sense of, if this SSL is just to confirm that the
site
> is genuine, then it is pointless for my cause. The only people who use
our
> site are the people have already been using it for a year or more. They
> already know its a valid site and have password and username to log-in.
It
> was the log-in process I was trying to make more secure with SSL, and
ensure
> that any files transfered couldn't be made sense of.
>
>

"Justin Tyme" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Paul D.Smith" <(E-Mail Removed)> wrote in message
> news:42787cc1$0$301$(E-Mail Removed) t...
> > Look for "Ethereal" - http://www.ethereal.org is a good starting place.
> > This is sniffer software that runs on a PC.

Actually, Ethereal is a protocol analyser. Packet capture (AKA sniffing) for
Windows is generally done by WinPCap, which Ethereal interfaces with.

> > Just a heads-up. SSL's certificates work as follows...
> >
> > 1. I've been offered a certificate that says "Mr X vouched me"
> > 2. Mr X has a certificate that says "Mr Y vouched me"
> > 3. Mr Y has a certificate that says "Mr Z vouched for me"
> >
> > Oh, Mr Z, you say. I know and trust him so if he vouched for Mr Y, I
> > trust them, and if Mr Y vouches for Mr X then I trust them too.
[snip]
> Oh. I wanted to use SSL to make sure no documents that were being
> transfered could be read or made sense of, if this SSL is just to confirm
> that the site is genuine, then it is pointless for my cause.

SSL covers both certification and encryption. A self-signed certificate (as
Paul mentioned) will probably suffice.

Alex