https confusion

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 <ToddMargoChester@invalid.com> (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 <never@drwxr-xr-x.org> wrote:
> Todd and Margo Chester <ToddMargoChester@invalid.com> (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

Todd and Margo Chester <ToddMargoChester@invalid.com> wrote in news:e1f31t
$poc$1@emma.aioe.org:

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

Just as a practical example. If you connect your browser to any bank site
that provides internet banking. They usually have a log in button. When you
click that you notice that the URL links to something like:

https:\\www.mybank.com/.....

You will notice that your browser should display an icon usually a padlock
next to say www.mybank.com at the status line at the bottom of the window. In
firefox, if you hover the mouse over the padlock it will pop up info saying
"Signed by <CA provider>". That says that the certficate received from the
server is a valid certificate issued by whoever the CA provider are (often
Verisign). That indicates that the server firefox is connected to is really
the correct server that CA provider issued with a certificate (note that
mybank have to pay Verign or other CA provider for the privilege, the
certificate often has an expiry date, which means that the bank have to
periodically cough up money to the CA provider get a new certificate issued).
If you double click on the padlock it will give you the full details.
Hopefully this indicates that your browser now has an encrypted SSL
connection to the bank's server and you can be reasonably sure that it is
your bank that you are connected to and not a phishing site. Make sure that
the name next to the padlock is what you expect e.g www.mybank.com. A phisher
could trick you to connect to a site with a valid certficate for say
www.mibank.com - you might notice that the name is not what it should be. So
far you are fairly certain that it is indeed the right bank's server that you
are talking to but they do not at this stage know who you are, as they allow
anyone to connect to this point. They only know who you are because you now
type in some sort of usercode and password that only you should know. As
other posters pointed out, it is possible to set things up so that the client
must also provide a CA signed certficate to the server.

Apache supports all this stuff and note that you don't need to use a CA to
provide certificates if you have control of both the client and server end
you can generate your own certificates assuming you trust yourself ;^), which
also has the advantage of being free. Check out the prices for Verisign
(ouch):

http://www.verisign.com/

If the general public are going to access then you really do need to use one
of the CA's that are built into the common browsers. If you don't, the
browser will pop up a dialog to the user saying saying something like "well I
received this certificate from the server but I don't know who the issuer is
- it's up to you if you believe it or not".

Klazmon.

CANNON-FODDER <CANNON@FODDER.COM> (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." <dozzie@dynamit.im.pwr.wroc.pl.nospam> (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 <never@drwxr-xr-x.org> wrote:
> "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> (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