https confusion

Hi All,

A customer has asked me to set up a secure web site
for all his road warriors to access a database
(sugar CRM via Apache). He has asked me this because
I have set him up several Linux servers in his company,
including their firewall.

The working of https have me baffled. How in
the world can you set up a secure connection, if you
do not have a "secret" key at both ends that the bad
guys are not aware of?

Seems to me that all the bad guys have to do is
to watch you log on to an https (monitor your traffic)
and they would know everything about how to duplicate
your log on.

The idea behind the customer's request is that
he only wants his road warriors to access the
site and only with encryption.

Can someone point me to a explanation of how https
works? Is https the correct route to go?

Many thanks,
--Todd

On 08.04.2006, Todd and Margo Chester <ToddMargoChester@invalid.com> wrote:
> A customer has asked me to set up a secure web site
> for all his road warriors to access a database
> (sugar CRM via Apache). He has asked me this because
> I have set him up several Linux servers in his company,
> including their firewall.
>
> The working of https have me baffled. How in
> the world can you set up a secure connection, if you
> do not have a "secret" key at both ends that the bad
> guys are not aware of?

Have you heard about assymetric cryptography? Sometimes called public
key cryptography.

> Seems to me that all the bad guys have to do is
> to watch you log on to an https (monitor your traffic)
> and they would know everything about how to duplicate
> your log on.

Nope.

> The idea behind the customer's request is that
> he only wants his road warriors to access the
> site and only with encryption.
>
> Can someone point me to a explanation of how https
> works? Is https the correct route to go?

It's simple. Firstly, a SSL/TLS tunnel is set up, and then normal HTTP
commands are sent to server.

If all your client needs is to securely connect via WWW browser, then
HTTPs should be OK, I think.

--
Feel free to correct my English
Stanislaw Klekot

Stachu 'Dozzie' K. wrote:

>> Seems to me that all the bad guys have to do is
>> to watch you log on to an https (monitor your traffic)
>> and they would know everything about how to duplicate
>> your log on.
>
> Nope.

I don't get why not? It seems to me that all the bad
guys have to do is watch the initial exchange of keys
and they got you.

It also seems to me that anyone can log in to the Sugar
CRM/Apache server. The only thing keeping them out
would the be their Sugar CRM username/password.

I log into https site ALL THE TIME. I am never
challenged for anything (that I know of).

On Fri, 07 Apr 2006 18:45:09 -0700, Todd and Margo Chester wrote:

> Hi All,
>
> A customer has asked me to set up a secure web site
> for all his road warriors to access a database (sugar CRM via Apache).
> He has asked me this because I have set him up several Linux servers in
> his company, including their firewall.
>
> The working of https have me baffled. How in
> the world can you set up a secure connection, if you do not have a
> "secret" key at both ends that the bad guys are not aware of?
>
> Seems to me that all the bad guys have to do is
> to watch you log on to an https (monitor your traffic) and they would
> know everything about how to duplicate your log on.
>
> The idea behind the customer's request is that
> he only wants his road warriors to access the site and only with
> encryption.
>
> Can someone point me to a explanation of how https
> works? Is https the correct route to go?
>
> Many thanks,
> --Todd

Hi Todd.
I am not unsympathetic to your issue, and not insensitive to the concerns
you obviously have. All is not lost, as it seems that you - at least - do
have an opportunity for truly and reasonably strong secure communications.
First, background from google:

http://www.google.com/search?q=encrypt+diffie

Crypto-Politics: Decoding the New Encryption Standard Diffie and Landau
recount the history of government policy on encryption. It is a story of
repeated attempts to limit public access to strong cryptography. ...
research.sun.com/features/encryption/ - 31k

RSA Security - 3.6.1 What is Diffie-Hellman? The Diffie-Hellman key
agreement protocol (also called exponential key ... The Diffie-Hellman key
exchange is vulnerable to a man-in-the-middle attack. ...
www.rsasecurity.com/rsalabs/node.asp?id=2248 - 18k

The NetIP Security Resource - Diffie-Helman Article Diffie-Hellman is not
an encryption mechanism as we normally think of them in ... Figure4
Encrypted Data Transmission. The use of Diffie-Hellman greatly ...
www.netip.com/articles/keith/diffie-helman.htm - 32k

... You get the idea. ...

Unfortunately, I am not the expert. Before we as a community can
collectively establish a general solution to a security problem, we need
to first be able to reach consensus agreement on the definition of what
that security problem is.

But first, as I am sure you may already know, virtually 100% of all
on-line purchases and other cash transactions do indeed take place under
the shadow of the concerns that you have voiced. These amount to ___
billions of dollars annually. Fill in your own researched statistics.
(Thanks!)

And here are a few anecdotes:

I use several ISP's (Internet Service Providers). One of my ISP's, (that
I did not choose and would not have chosen) had an extraordinarily high
level of unsolicited and critically hostile unsolicited traffic. I have
several measures in place to protect my systems and to selectively notify
the "abuse" departments of problem issues. My systems were indeed
protected and the offending ISP('s) were indeed properly notified, and
most indeed responded with e-mail assurances that the issues would be
investigated and corrected. But the abuse from this one ISP continued
unabated. I made several telephone calls, - at least half a dozen. And
the representatives of this ISP presented me with consecutive evasions,
delays and outright open and offensive hostility. Persisting, I finally
connected with a nice (young?) lady, who seemed slightly perplexed by the
issues and the (CRM) history of all my calls. I explained some of my
concerns with botnets, dDoS's, organized crime and terrorism to her, and
seemed to connect. The attacks have not completely stopped, but perhaps
they are at least coming from different IP addresses via DHCP. That issue
is not completely gone, but it is improved. Thanks (sincere thanks) to
that one lady. The lesson here is that it is not simply enough to be able
to recognize the vectors of attack, but to also have the resolve to
neutralize those vectors. Minor, perhaps. But a good example and case in
point of the stonewalls that we face in asking for and receiving secure
internet service.

Another anecdote involves a third-party account of criminal activity that
gained access to private network data via a backdoor that was established
to allow law-enforcement authorities to trace (some?) (supposedly,
allegedly) questionable communications. The crime would not have been
possible without the "official" demand for backdoor access to "secure"
internet communications.

And the third story is about MITM. If an ISP is threatened and
intimidated by anyone as formidable as the United States Department of
Justice, to allow it to place MITM software on a server or router, who
would dare say no? Who would dare question them about security? But the
DOJ, the DOD and virtually every other US Government system has been
repeatedly "broken into", so they say. So anything the DOJ, etc., has, is
freely available to crackers, criminals and organized crime. -- Very,
very bad. No emoticon appropriate to torture and indefinite, warrentless
imprisonment. No checks and balances. No Judicial review. No
Congressional review. Use your own sense of History, please, to draw any
appropriate parallels. Thank you.

Yet we are (legally????) prevented and forbidden from (technologically
feasible) detection of the locations of the MITM vectors, established by
the US Government, and increasingly by Governments in countries on other
continents.

It is not at all impossible to detect and remove MITM nodes, except for
the constraints of governments that are "protecting us". Without that,
the community could deal with this.

The bottom line here is that as long as "Government" can authorize and
demand warrentless searches of any and everything, then it must be assumed
that everything on the internet is open to organized crime, and worse, if
worse exists.

The good news is that there is a ready, viable effective solution to your
particular (and very valid) issue. Generate encryption keys for all your
road warriors. -- Not the same keys, but different keys for each warrior.
You can use lesser protection for intermediate usage during the
change-over. But give each warrior (personally place in his/her hand or
install onto his/her notebook) his/her own key set. When that man
or woman goes over the edge, loses the notebook, sells out, etc., Only
that single key is compromised. They can then each connect via an
encrypted channel that is _not_ subject to MITM attack, and you can set up
whatever HTTP pages for them that you need.

I am not the expert but believe this is correct. Perhaps someone more
knowledgeable will add or supplement, or even say where this is wrong. If
this can help you then It is well worth my effort to me, and I hope at
some point that you will share the benefits of your experience with the
rest of us. I would help with research if that could be important.

Usually, on group conversations are most appropriate. E-mail me if
necessary.

colloquy_no_9 (at) mailingaddress.org

I wish you very good success, sir and madame. All good fortune to you.

"Todd and Margo Chester" <ToddMargoChester@invalid.com> wrote in message
news:e174ib$le1$1@emma.aioe.org...

> The working of https have me baffled. How in
> the world can you set up a secure connection, if you
> do not have a "secret" key at both ends that the bad
> guys are not aware of?

You do. It is negotiated in the process of establishing an https
session.

> Seems to me that all the bad guys have to do is
> to watch you log on to an https (monitor your traffic)
> and they would know everything about how to duplicate
> your log on.

There are only two ways the bad guys could do this:

1) Without modifying any of the data, in which case all they would be
doing is letting you do exactly what you wanted to do. They couldn't
understand any of the data exchanged because they wouldn't have the
negotiated key.

2) With modifying the data, in which case the change would be noticed
because all data exchanged is checksummed.

> The idea behind the customer's request is that
> he only wants his road warriors to access the
> site and only with encryption.

Right.

> Can someone point me to a explanation of how https
> works? Is https the correct route to go?

It's basically this:

1) The client connects to the server.

2) The server sends the client proof that it is in fact the server the
client has asked for.

3) The client and server negotiate a shared secret known only to them
using a mechanism such that no third party intercepting the communication
could determine the shared secret.

4) The rest of the communication is encrypted and validated using that
shared secret.

DS

On Sat, 08 Apr 2006 01:59:32 -0400, Newsbox wrote:

>
> Another anecdote involves a third-party account of criminal activity that
> gained access to private network data via a backdoor that was established
> to allow law-enforcement authorities to trace (some?) (supposedly,
> allegedly) questionable communications. The crime would not have been
> possible without the "official" demand for backdoor access to "secure"
> internet communications.
>
> And the third story is about MITM. If an ISP is threatened and
> intimidated by anyone as formidable as the United States Department of
> Justice, to allow it to place MITM software on a server or router, who
> would dare say no? Who would dare question them about security? But the
> DOJ, the DOD and virtually every other US Government system has been
> repeatedly "broken into", so they say. So anything the DOJ, etc., has, is
> freely available to crackers, criminals and organized crime. -- Very,
> very bad. No emoticon appropriate to torture and indefinite, warrentless
> imprisonment. No checks and balances. No Judicial review. No
> Congressional review. Use your own sense of History, please, to draw any
> appropriate parallels. Thank you.
>
> Yet we are (legally????) prevented and forbidden from (technologically
> feasible) detection of the locations of the MITM vectors, established by
> the US Government, and increasingly by Governments in countries on other
> continents.
>
> It is not at all impossible to detect and remove MITM nodes, except for
> the constraints of governments that are "protecting us". Without that,
> the community could deal with this.
>
> The bottom line here is that as long as "Government" can authorize and
> demand warrentless searches of any and everything, then it must be assumed
> that everything on the internet is open to organized crime, and worse, if
> worse exists.
>

Good post, newsbox.

http://yro.slashdot.org/article.pl?sid=06/04/07/1246259

http://it.slashdot.org/article.pl?sid=06/04/07/1942259

On Sat, 8 Apr 2006 01:39:37 -0700, David Schwartz <davids@webmaster.com> wrote:
>
> "Todd and Margo Chester" <ToddMargoChester@invalid.com> wrote in message
> news:e174ib$le1$1@emma.aioe.org...

>> Can someone point me to a explanation of how https
>> works? Is https the correct route to go?
>
> It's basically this:
>
> 1) The client connects to the server.
>
> 2) The server sends the client proof that it is in fact the server the
> client has asked for.
>
> 3) The client and server negotiate a shared secret known only to them
> using a mechanism such that no third party intercepting the communication
> could determine the shared secret.
>
> 4) The rest of the communication is encrypted and validated using that
> shared secret.

To add some essential detail:

2a: The server sends the client (1) the server's public key,
and (2) a certificate attesting that that public key
belongs to the client's internet address, signed by some
certification authority like Verisign.

2b: The client verifies that the public key and client
address are indeed the ones for which the certificate
was generated, and verifies that the certificate is
valid by referring to the client's database of
certificate-issuers' public keys (web browsers come with
this database built in).

3: The key-negotiation protocol guarantees to the client that
no eavesdropper can reconstruct the correct key without knowing
the private key that corresponds to the server's public key.

For Todd and Margos' application, it is significant that the
server has no guarantee of the client's identity. For normal
Web commerce, that doesn't matter, since the merchant (server)
will accept anybody's credit card number, but the customer
(client) doesn't want to give his credit card number to just
anybody.

I believe there are provisions for bi-directional SHTML
authentication, but I don't know.

Don't Todd and Margo really want a Virtual Private Network
(VPN)?

--
To email me, substitute nowhere->spamcop, invalid->net.

On 2006-04-08, Peter Pearson <ppearson@nowhere.invalid> wrote:
> On Sat, 8 Apr 2006 01:39:37 -0700, David Schwartz <davids@webmaster.com> wrote:
>>
>> 1) The client connects to the server.
>>
>> 2) The server sends the client proof that it is in fact the server the
>> client has asked for.
>>
>> 3) The client and server negotiate a shared secret known only to them
>> using a mechanism such that no third party intercepting the communication
>> could determine the shared secret.
>>
>> 4) The rest of the communication is encrypted and validated using that
>> shared secret.
>
> To add some essential detail:
>
> 2a: The server sends the client (1) the server's public key,
> and (2) a certificate attesting that that public key
> belongs to the client's internet address, signed by some
> certification authority like Verisign.

Since we're adding detail, certificates may be self-signed, in which
case the browser (or the user) needs to verify that the certificate is
the correct one. Also, in general if the certificate is signed by a CA
in the browser's database, all it means is that the admin of the server
is the one who paid the CA for a valid cert; it doesn't mean that the
content is at all accurate or represents who it says it does (e.g., I
could register myebay.com, which doesn't seem to be registered, get a
cert, and copy eBay's content; an unwise user might be fooled into
thinking that I actually represent eBay).

> 3: The key-negotiation protocol guarantees to the client that
> no eavesdropper can reconstruct the correct key without knowing
> the private key that corresponds to the server's public key.

I don't think this is guaranteed, just highly likely. IOW, it's highly
unlikely that someone could crack the session, but I don't think it's
absolutely impossible.

> Don't Todd and Margo really want a Virtual Private Network
> (VPN)?

Maybe, maybe not. I think they need to tell us, not vice-versa. :)
Perhaps it's enough to have a secure connection with clients using
passwords to access sensitive material.

--keith

--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom
see X- headers for PGP signature information

On Fri, 07 Apr 2006 18:45:09 -0700, Todd wrote:
[snip]
>
> The idea behind the customer's request is that
> he only wants his road warriors to access the
> site and only with encryption.
>
> Can someone point me to a explanation of how https
> works? Is https the correct route to go?

Hey, Wikipedia has a pretty decent entry on HTTPS, which
says, in part,

The system can also be used for client authentication,
in order to restrict access to a web-server to only
authorized users. For this, typically the site
administrator creates certificates for each user, which
are loaded into their browser, although certificates
signed by any certificate authority the server trusts,
should work. These normally contain the name and e-mail
of the authorized user, and are automatically checked by
the server on each reconnect to verify the user's
identity, potentially without ever entering a password.

--
To email me, substitute nowhere->spamcop, invalid->net.

On Sat, 08 Apr 2006 22:50:06 GMT, Peter Pearson wrote:
> On Fri, 07 Apr 2006 18:45:09 -0700, Todd wrote:
> [snip]
>>
>> The idea behind the customer's request is that
>> he only wants his road warriors to access the
>> site and only with encryption.
>>
>> Can someone point me to a explanation of how https
>> works? Is https the correct route to go?
>
> Hey, Wikipedia has a pretty decent entry on HTTPS, which
> says, in part,

[snip]

Two additional comforting observations:

1. Figure 1 at
http://httpd.apache.org/docs-2.0/ssl/ssl_intro.html
shows where in the SSL protocol the server gets a
chance to ask the client for a certificate. SSL
(essentially the same as TLS) is the secure-session
protocol on which HTTPS is built.

2. The Firefox browser I'm running, under
Edit / Preferences / Advanced / Certificates,
has a box labelled "Client Certificate Selection" to
"Decide how Firefox selects a security certificate to
present to web sites that require one." Sounds like
exactly what Todd needs.

--
To email me, substitute nowhere->spamcop, invalid->net.