On 08.04.2006, Todd and Margo Chester 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" 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 wrote:
>
> "Todd and Margo Chester" 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 wrote:
> On Sat, 8 Apr 2006 01:39:37 -0700, David Schwartz 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.

On Sat, 08 Apr 2006 15:14:43 +0000, John wrote:

[...]
>> 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

Thanks for saying so John. And thanks for those links.

http://news.yahoo.com/s/nm/20060408/...ush_vermont_dc

Todd and Margo Chester (06-04-07 18:45:09):

> Hi All,

Hello. Others have postet correct answers already. But I'd like to get
more technical, so you understand what you are doing, and what you need
in order to do it. And I don't want to start hundrets of sub-threads.
So I'm starting my own.


> 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.

Well, 'secure' is very discrete. 'Secure' in what terms?


> 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?

This is possible since (roughly) 1976. It's called asymmetric
cryptography, as Stachu K. already pointed out. In asymmetric
cryptography, you split the single encryption/decryption key into two
keys, which are inverse to each other. In other words, if you encrypt
with the first key, you can only decrypt with the second, and if you
encrypt with the second, then you can only decrypt with the first. That
allows both encryption and authentication (the latter one includes
electronic signatures, i.e. it guarantees authenticity).

Now you can do that key splitting in classic symmetric cryptography as
well. But this method is called 'asymmetric cryptography', because you
cannot derive one key from the other (easily), unless you know a certain
secret. It's 'asymmetric', because that derivation is easy for one who
does know it, and hard for everyone else. You can say that symmetric
cryptography uses two separate keys, too, but one is easily derivable
from the other for everyone. In most symmetric cases, both keys are
identical.

So let's create such a key pair. First, we choose a secret and create a
'public key' (the first key). Then we derive the particular secret key
(the second key) using that secret. Nobody else knows the secret, so
they cannot reconstruct that derivation. At last, you give your public
key to others.

Encryption: Those others can encrypt messages to you using that public
key. Because the secret key is needed to recover the encrypted message,
only you can decrypt it. They cannot get the secret key, because they
don't know your secret. An attacker will not gain any information by
intercepting the public key, because it's public anyway. The secret key
will never be transmitted.

Signatures: This simply works the other way round. You can sign a
message by encrypting it with your secret key. Others can verify that
the message is from you by checking if it decrypts correctly with the
public key. That's a very simplified explanation. Technically it's a
bit more complicated (using hash functions).

Authentication: It's the same as signatures. You have the public key
of a person and you would like to verify that you are talking to him.
So you give him a random message and let him encrypt it with his secret
key, and send it back to you. You verify that it properly decrypts with
the public key. Again that's over-simplified.

There are lots of asymmetric cryptosystems now, but most of them rely on
the difficulty to solve one of three problems: the 'integer
factorization problem', the 'discrete logarithm problem' (DLP) and the
'elliptic curve discrete logarithm problem' (ECDLP). The former two
problems are very related and many people assume that they are
identical. But that's not proven. The ECDLP is a totally different
problem.

To illustrate this, the Rabin cryptosystem relies on the integer
factorization problem. You take two large prime numbers. They (both)
are your secret, and at the same time form your secret key. You
multiplicate them together, and that product is the public key, which
you can distribute freely.

One cannot get your secret key, because they lack the knowledge of those
two prime numbers. They cannot learn them from the product (the public
key), because factorizing that product is impractical to do currently
(assuming that the prime numbers are large enough).

A non-cryptographic application of asymmetric cryptography is key
agreement. For example, the Diffie-Hellmen-Protocol allows for
negotiating a secret number, which can be used as a key, and which
cannot be intercepted.

However, current asymmetric methods are all subject to an attack called
the MITM (man in the middle) attack. There is another very long thread,
where we have addressed that issue in another context. It might be very
interesting to you. Seek for the thread with the topic "Any reasons to
filter ARP packets?" in this group.


> 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.

No. See above. They need to be that MITM guy to do that. And by using
constant key pairs (key-based authentication), you can effectively
prevent even that.


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

So the information is confidental and needs to be transmitted
authentically. In other words, you need both encryption and
authentication.


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

HTTPS (HTTP/SSL), or 'secure HTTP' is in fact HTTP, but encapsulated
into SSL. With SSL you can encrypt and authenticate the messages
transmitted, without changing the actual application protocol (HTTP in
this case). So you are basically asking, how SSL works.

The SSL (secure sockets layer) is a container protocol and uses
asymmetric cryptography for key negotiation and authentication. The
server owns something called a certificate, which includes its public
key. The client receives the server's certificate and verifies that
it's correct (i.e. does not contain a forged key -- see the MITM
attack). To do this, something called a 'certificate authority' (CA) is
used. This is another server (sometimes called a 'trust center'), which
knows all certificates from all servers in question. The client needs
to own the CA's certificate in the first place to communicate securely
with it.

To be more practical, let's assume there is a CA called TrustedCompany.
All clients own a valid certificate from it. A server owner now gets
(buys) a certificate from TrustedCompany for his server. Now a client
connecting to that server receives the certificate. Naturally it would
like to verify that it's correct, so it takes TrustedCompany's
certificate (which it already has) and asks TrustedCompany if the
server's certificate is alright. TrustedCompany confirms its
correctness, and the client is convinced.

Now with HTTPS there is a big problem. Because only very few browsers
allow client side authentication, you can only authenticate the server.
The client needs to be authenticated via standard HTTP. That's not
necessarily insecure, but you better check that there is no MITM.

In other words: In most cases, HTTPS is only appropriate for server
side authentication. If there is an MITM, he can intercept at least all
traffic from the server to the client. Normally MITMs are detected and
warned about by software, but I wouldn't count on that.

If you gave us more information about the application, then we might be
able to recommend other solutions than HTTPS.


Regards.

Ertugrul Soeylemez wrote:
....
> However, current asymmetric methods are all subject to an attack called
> the MITM (man in the middle) attack. There is another very long thread,
> where we have addressed that issue in another context. It might be very
> interesting to you. Seek for the thread with the topic "Any reasons to
> filter ARP packets?" in this group.
>
>> 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.
>
> No. See above. They need to be that MITM guy to do that. And by using
> constant key pairs (key-based authentication), you can effectively
> prevent even that.
>
>> The idea behind the customer's request is that he only wants his
>> road warriors to access the site and only with encryption.
>
> So the information is confidental and needs to be transmitted
> authentically. In other words, you need both encryption and
> authentication.
....
> The SSL (secure sockets layer) is a container protocol and uses
> asymmetric cryptography for key negotiation and authentication. The
> server owns something called a certificate, which includes its public
> key. The client receives the server's certificate and verifies that
> it's correct (i.e. does not contain a forged key -- see the MITM
> attack). To do this, something called a 'certificate authority' (CA) is
> used. This is another server (sometimes called a 'trust center'), which
> knows all certificates from all servers in question. The client needs
> to own the CA's certificate in the first place to communicate securely
> with it.
>
> To be more practical, let's assume there is a CA called TrustedCompany.
> All clients own a valid certificate from it. A server owner now gets
> (buys) a certificate from TrustedCompany for his server. Now a client
> connecting to that server receives the certificate. Naturally it would
> like to verify that it's correct, so it takes TrustedCompany's
> certificate (which it already has) and asks TrustedCompany if the
> server's certificate is alright. TrustedCompany confirms its
> correctness, and the client is convinced.
>
> Now with HTTPS there is a big problem. Because only very few browsers
> allow client side authentication, you can only authenticate the server.
> The client needs to be authenticated via standard HTTP. That's not
> necessarily insecure, but you better check that there is no MITM.
>
> In other words: In most cases, HTTPS is only appropriate for server
> side authentication. If there is an MITM, he can intercept at least all
> traffic from the server to the client. Normally MITMs are detected and
> warned about by software, but I wouldn't count on that.
>
....
> Regards.

Just wondering...

This product (URL below) is just such a MITM attack, correct? [1]
http://www.cyberguard.com/products/w...tml?lang=de_EN
http://www.cyberguard.com/products/w...tml?lang=de_EN

How does this work with Certificate Authorities? [2] Is the ability to
decrypt limited to the case where the clients behind the [assumed]
corporate net: are authenticating to specific CA certificates, or have to
have modified 'TrustedCompany' certificates and/or certificates for the
proxy server?

If I have this right, the client should be seeing the proxy server's
certificate not the [target server's] certificate. Would this work
differently with the self-signed certificates?

Could this be set up at a hotel, coffee shop, airport, etc. and still work
[transparently]?

Could this setup with logging [vice filtering] be set up at a corporation
that logs all traffic - including any external customer/partner/supplier
who needs to connect to their [homebase] as a matter of conducting
business?



[1] I understand the intent of the software, but Primrose Path, etc.
[2] I understand one of the intended 'benefits' is to [coddle] clients by
maintaining currency with revocation lists, or blocking known mimic type
[myebay.com] certificates.

v/r,
C-F
collinsd_kc.rr.com

"Under the Hood of AT&T's Monitoring System" (Slashdot news Item)

http://yro.slashdot.org/yro/06/04/09/1657258.shtml

On 09.04.2006, Ertugrul Soeylemez wrote:
> Todd and Margo Chester (06-04-07 18:45:09):
[...]
>> 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?
>
> This is possible since (roughly) 1976. It's called asymmetric
> cryptography, as Stachu K. already pointed out. In asymmetric
> cryptography, you split the single encryption/decryption key into two
> keys, which are inverse to each other. In other words, if you encrypt
> with the first key, you can only decrypt with the second, and if you
> encrypt with the second, then you can only decrypt with the first. That
> allows both encryption and authentication (the latter one includes
> electronic signatures, i.e. it guarantees authenticity).

By the way, that's not an universal true that you use private key for
_encryption_ in digital signatures. That's true for RSA, but when
talking about ElGamal, well, digital signature is not encryption. In RSA
we have quite symmetric situation (private exponent d is an inverse of
public exponent e and vice versa). In ElGamal private key x is an
exponent, while public key y is g^x for some g. It's clear that usually
g^y is not equal to x. Digital signatures in ElGamal scheme are
validated without computing original signed document.

[...]
> There are lots of asymmetric cryptosystems now, but most of them rely on
> the difficulty to solve one of three problems: the 'integer
> factorization problem', the 'discrete logarithm problem' (DLP) and the
> 'elliptic curve discrete logarithm problem' (ECDLP). The former two
> problems are very related and many people assume that they are
> identical. But that's not proven. The ECDLP is a totally different
> problem.

Different? I don't think so. ECDLP is simple DLP, but defined in
different group (elliptic curves with addition instead of naturals
modulo some number with multiplication). It's additional algebraic
properties of (EC,+) that makes DLP more difficult.

--
Feel free to correct my English
Stanislaw Klekot

Todd and Margo Chester wrote:

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


Wow! Thank you all for the excellent replies. I know
(think) I understand. :-)

--Todd

CANNON-FODDER (06-04-09 20:47:39):

> Just wondering...
>
> This product (URL below) is just such a MITM attack, correct? [1]
> http://www.cyberguard.com/products/w...tml?lang=de_EN
> http://www.cyberguard.com/products/w...tml?lang=de_EN

Yes, the gateway needs to be the MITM in that case. But you need to
consider that I'm talking about theory here, not about specific
products. HTTP/SSL in the default configuration is not very secured
against MITMs, because only the traffic from the client to the server is
MITM-resistant. So the gateway is in fact able to intercept and
manipulate data sent the other way. The feature set describes filtering
capabilities, which are theoretically possible.

Well, today when removing some unused extensions, I have found out that
you can select client certificates in Firefox. This would make the
connection completely MITM-resistant (and the product useless), as long
as the server knows the client's certificate and does verify it.
Unfortunately, that's mostly not the case.


> How does this work with Certificate Authorities? [2] Is the ability to
> decrypt limited to the case where the clients behind the [assumed]
> corporate net: are authenticating to specific CA certificates, or have
> to have modified 'TrustedCompany' certificates and/or certificates for
> the proxy server?

The case is that the client owns a default set of certificates from well
known CAs (including VeriSign, TC TrustCenter, and others). Now when
the server has bought a certificate from a CA, then that certificate is
signed by that particular CA. If you have the CA's certificate, then
you can verify that signature, and hence trust that server's certificate.

But that's not enough. First, you need to make sure that you get your
browser package from an authentic source (i.e. not from within the
company's network). If you don't, then the certificates could have been
tampered with. The bigger problem is that the servers, you connect to,
need to know your certificate (which you must make sure). In other
words: It's a mess.

To have a totally secure connection to a server, the following
requirements must be fulfilled:

* The server owns a certificate, which you can authenticate. This
means, that it's signed by a CA, which you have a certificate of
(e.g. VeriSign or TC TrustCenter). It can also use a self-signed
certificate (not to verify by a CA's certificate). But in that case,
you must make sure that you've got that certificate from an authentic
source (not from within the company's network).

* The client owns a certificate, which the server authenticates. This
can again be done by a CA, but that's normally not the case. So you
must make sure that the server knows that certificate (upload it via a
secure channel, or hand it to the server administrator on a floppy
disk). And the server _must_ verify its correctness, i.e. compare it
to the certificate, which you gave it over a secure line.

The latter part is more difficult. But if you meet this requirements,
then the software package, you talked about, can prevent the
communication at best. It's not able to intercept or manipulate
anymore.


> If I have this right, the client should be seeing the proxy server's
> certificate not the [target server's] certificate.

Most browsers warn you about certificates, which are signed with an
unknown CA's certificate, signed with itself (self-signed) or not signed
at all. This includes popular browsers like Firefox, Opera, Konqueror,
Galeon, and others. They ask you, if you really want to connect to that
server. I call those certificates 'untrusted'. This is the case, when
either the server really does own an untrusted certificate, or when the
MITM has replaced the trusted certificate by another one.

So no, the MITM is not able to replace the server's certificate without
being detected. The case is that the server sees another certificate
(if it sees one at all). It would detect this, if it checked that
certificate for validity. As mentioned above, most servers cannot do
this, as they need to know your client's certificate in the first place.


> Would this work differently with the self-signed certificates?

The problem with self-signed certificates, as already pointed out, is
that you cannot distinguish the original certificate from the MITM's
one. At least, your browser is going to warn you about that fact.


> Could this be set up at a hotel, coffee shop, airport, etc. and still
> work [transparently]?

Yes.


> Could this setup with logging [vice filtering] be set up at a
> corporation that logs all traffic - including any external
> customer/partner/supplier who needs to connect to their [homebase] as
> a matter of conducting business?

Yes. But remember: Only server-to-client traffic can be logged. The
other way is problematic to the MITM, because he would be detected in
that case.


> [1] I understand the intent of the software, but Primrose Path, etc.
> [2] I understand one of the intended 'benefits' is to [coddle] clients
> by maintaining currency with revocation lists, or blocking known mimic
> type [myebay.com] certificates.

Again, only server-to-client. They cannot prevent you from using
certain CAs, as long as you have their certificate.


Regards.

"Stachu 'Dozzie' K." (06-04-10 15:34:31):

> > > 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?
> >
> > This is possible since (roughly) 1976. It's called asymmetric
> > cryptography, as Stachu K. already pointed out. In asymmetric
> > cryptography, you split the single encryption/decryption key into
> > two keys, which are inverse to each other. In other words, if you
> > encrypt with the first key, you can only decrypt with the second,
> > and if you encrypt with the second, then you can only decrypt with
> > the first. That allows both encryption and authentication (the
> > latter one includes electronic signatures, i.e. it guarantees
> > authenticity).
>
> By the way, that's not an universal true that you use private key for
> _encryption_ in digital signatures. That's true for RSA, but when
> talking about ElGamal, well, digital signature is not encryption. In
> RSA we have quite symmetric situation (private exponent d is an
> inverse of public exponent e and vice versa). In ElGamal private key x
> is an exponent, while public key y is g^x for some g. It's clear that
> usually g^y is not equal to x. Digital signatures in ElGamal scheme
> are validated without computing original signed document.

No, you confuse 'private key' (which is a construct) with 'private
exponent' (which is a number). You need the ElGamal private key to sign
a message, and you need the public key to verify the signature.

You are right in that in ElGamal it's not encryption, but I also didn't
claim that. And RSA is in no way symmetric, because in cryptography
'asymmetry' refers to the difficulty of deriving one key from another
(possibly depending on a secret). In RSA it's difficult to derive d
from e (and vice versa) without knowing the totient phi(n), where n is
the modulus.


> > There are lots of asymmetric cryptosystems now, but most of them
> > rely on the difficulty to solve one of three problems: the 'integer
> > factorization problem', the 'discrete logarithm problem' (DLP) and
> > the 'elliptic curve discrete logarithm problem' (ECDLP). The former
> > two problems are very related and many people assume that they are
> > identical. But that's not proven. The ECDLP is a totally different
> > problem.
>
> Different? I don't think so. ECDLP is simple DLP, but defined in
> different group (elliptic curves with addition instead of naturals
> modulo some number with multiplication). It's additional algebraic
> properties of (EC,+) that makes DLP more difficult.

Yes, but the EC group is a lot different from finite fields. Formally
it's the same problem, but numerically it's totally different.
Otherwise you could take integer methods to solve the DLP, and apply
them to elliptic curves, which is not possible (easily).


Regards.

On 17.04.2006, Ertugrul Soeylemez wrote:
> "Stachu 'Dozzie' K." (06-04-10 15:34:31):
>
>> > > 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?
>> >
>> > This is possible since (roughly) 1976. It's called asymmetric
>> > cryptography, as Stachu K. already pointed out. In asymmetric
>> > cryptography, you split the single encryption/decryption key into
>> > two keys, which are inverse to each other. In other words, if you
>> > encrypt with the first key, you can only decrypt with the second,
>> > and if you encrypt with the second, then you can only decrypt with
>> > the first. That allows both encryption and authentication (the
>> > latter one includes electronic signatures, i.e. it guarantees
>> > authenticity).
>>
>> By the way, that's not an universal true that you use private key for
>> _encryption_ in digital signatures. That's true for RSA, but when
>> talking about ElGamal, well, digital signature is not encryption. In
>> RSA we have quite symmetric situation (private exponent d is an
>> inverse of public exponent e and vice versa). In ElGamal private key x
>> is an exponent, while public key y is g^x for some g. It's clear that
>> usually g^y is not equal to x. Digital signatures in ElGamal scheme
>> are validated without computing original signed document.
>
> No, you confuse 'private key' (which is a construct) with 'private
> exponent' (which is a number).

Right. That was too big simplification.

> You need the ElGamal private key to sign
> a message, and you need the public key to verify the signature.

Did I say something else?

> You are right in that in ElGamal it's not encryption, but I also didn't
> claim that.

No?

>> > In other words, if you
>> > encrypt with the first key, you can only decrypt with the second,
>> > and if you encrypt with the second, then you can only decrypt with
>> > the first.

In ElGamal you don't encrypt data with private key, as far as I can
recall.

> And RSA is in no way symmetric, because in cryptography
> 'asymmetry' refers to the difficulty of deriving one key from another
> (possibly depending on a secret). In RSA it's difficult to derive d
> from e (and vice versa) without knowing the totient phi(n), where n is
> the modulus.

I didn't talk about that. I said that public and private exponent are
indistinguishable (except that d != e) and _in this_ they are symmetric.

--
Feel free to correct my English
Stanislaw Klekot

"Stachu 'Dozzie' K." (06-04-17 09:57:17):

> > You need the ElGamal private key to sign a message, and you need the
> > public key to verify the signature.
>
> Did I say something else?

No, I just wanted clarify my point. No offense. =)


> > You are right in that in ElGamal it's not encryption, but I also
> > didn't claim that.
>
> No?

No. See below.


> > > > In other words, if you encrypt with the first key, you can only
> > > > decrypt with the second, and if you encrypt with the second,
> > > > then you can only decrypt with the first.
>
> In ElGamal you don't encrypt data with private key, as far as I can
> recall.

Yes, that's true. You don't do this. But remember that ElGamal is only
half-asymmetric. Computing the private key from the secret key is hard,
but the other way is easy, as the secret key is already the secret you
need to know to get it.


> > And RSA is in no way symmetric, because in cryptography 'asymmetry'
> > refers to the difficulty of deriving one key from another (possibly
> > depending on a secret). In RSA it's difficult to derive d from e
> > (and vice versa) without knowing the totient phi(n), where n is the
> > modulus.
>
> I didn't talk about that. I said that public and private exponent are
> indistinguishable (except that d != e) and _in this_ they are
> symmetric.

That's theory, and you are right. But in practice that's
implementation-specific, and in most implementations e is hard-coded.


Regards.