https confusion - Security

This is a discussion on https confusion - Security ; 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 ...

+ Reply to Thread
Results 1 to 20 of 20

Thread: https confusion

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

  2. Re: https confusion

    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

  3. Re: https confusion

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

  4. Re: https confusion

    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.

  5. Re: https confusion


    "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



  6. Re: https confusion

    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



  7. Re: https confusion

    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.

  8. Re: https confusion

    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


  9. Re: https confusion

    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.

  10. Re: https confusion

    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.

  11. Re: 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

  12. Re: https confusion

    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.

  13. Re: https confusion

    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

  14. Re: https confusion


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

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

  15. Re: https confusion

    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

  16. Re: https confusion

    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

  17. Re: https confusion

    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.

  18. Re: https confusion

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

  19. Re: https confusion

    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

  20. Re: https confusion

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

+ Reply to Thread