SSL info

Discussion in 'Computer Security' started by UKuser, Jan 2, 2007.

  1. UKuser

    UKuser Guest

    Hi Folks,

    I'm going to be working with some SSL pages (php) and wondered if there
    were any good design/development sites for security tips etc so I miss
    out on making the "obvious" blunders - whatever they may be.

    I've found: http://blogs.msdn.com/ie/archive/2005/04/20/410240.aspx
    which is very good and lists two possible problems. Here then is the
    newbie question.

    If a form is hosted on a HTTP (non secure) site and points to a HTTPS
    in the action tag, does this mean that the page has already made the
    SSL connection/handshake? Does the browser recognise the potential for
    a HTTPS connection and therefore do the same as if it was a full SSL
    page?

    Secondly, why is mixed content so bad (any sites would be great)? I
    appreciate various elements could be secure/unsecure but how would that
    pose a risk?

    Thanks

    UkUsEr
     
    UKuser, Jan 2, 2007
    #1
    1. Advertising

  2. UKuser wrote:

    > I'm going to be working with some SSL pages (php) and wondered if there
    > were any good design/development sites for security tips etc so I miss
    > out on making the "obvious" blunders - whatever they may be.


    The obvious blunders are incompetent Root-CA s. You can easily recognize
    them: If they're claiming to be Root-CA, then they're incompetent.

    > I've found: http://blogs.msdn.com/ie/archive/2005/04/20/410240.aspx
    > which is very good and lists two possible problems. Here then is the
    > newbie question.
    >
    > If a form is hosted on a HTTP (non secure) site and points to a HTTPS
    > in the action tag, does this mean that the page has already made the
    > SSL connection/handshake?


    No.

    > Does the browser recognise the potential for
    > a HTTPS connection and therefore do the same as if it was a full SSL
    > page?


    Yes. However, this won't help if the attacker can modified the unsecure
    form to transmit the content to somewhere else.

    > Secondly, why is mixed content so bad (any sites would be great)? I
    > appreciate various elements could be secure/unsecure but how would that
    > pose a risk?


    Simple: The nonsecure content can be modified by an attacker, and such a
    modified content can also modify/overwrite/extend the secure content.

    Trivial example: Overwrite an nonsecure CSS stylesheet with "body {
    display:none; visible: no; content-before:<!-- put your phishing website
    here -->}"
     
    Sebastian Gottschalk, Jan 2, 2007
    #2
    1. Advertising

  3. "UKuser" <> writes:
    > I'm going to be working with some SSL pages (php) and wondered if there
    > were any good design/development sites for security tips etc so I miss
    > out on making the "obvious" blunders - whatever they may be.
    >
    > I've found: http://blogs.msdn.com/ie/archive/2005/04/20/410240.aspx
    > which is very good and lists two possible problems. Here then is the
    > newbie question.
    >
    > If a form is hosted on a HTTP (non secure) site and points to a HTTPS
    > in the action tag, does this mean that the page has already made the
    > SSL connection/handshake? Does the browser recognise the potential for
    > a HTTPS connection and therefore do the same as if it was a full SSL
    > page?
    >
    > Secondly, why is mixed content so bad (any sites would be great)? I
    > appreciate various elements could be secure/unsecure but how would that
    > pose a risk?


    originally SSL was suppose to address two issues 1) are you really
    talking to the server that you think you are talking to and 2)
    encryption (hiding) of transmitted information.

    for #1, the user typed in the URL of the server they wanted to talk
    to, the server returned a SSL domain name server digital certificate,
    the browser validated the digital certificate and then compared the
    domain name in the user supplied URL with the domain name in the
    digital certificate.

    some posts about working on this long ago and far away with a
    small client/server startup that wanted to do payment transactions
    http://www.garlic.com/~lynn/aadsm5.htm#asrn2
    http://www.garlic.com/~lynn/aadsm5.htm#asrn3

    they had this technology called SSL ... and the payment transaction
    processing has since come to be called e-commerce. some number
    of past posts mentioning SSL processing
    http://www.garlic.com/~lynn/subpubkey.html#sslcert

    fairly quickly a problem cropped up ... merchants discovered that
    using SSL for the complete processing cut their processing thruput by
    80-90percent ... so they restricted SSL for just the checkout/payment
    processing. So now a user enters a non-SSL URL ... which doesn't check
    to see that the server that the user is talking to, is really the
    server that the user thinks they are talking to.

    the users click on a server provided button ... which supplies the
    (SSL) URL. In this situation ... rather than checking that the server
    is the server the user thinks they are talking to ... the only thing
    it does is checks that the server is whoever they claim to be
    (i.e. the server provides both the URL with a domain name as well as
    the digital certificate with the domain name). it would take a fairly
    inexperienced to claim to be one server and not be able to provide a
    digital certificate that substantiates that claim. this is also what
    is behind some of the phishing emails that can provide (SSL) URLs to
    click-thru on ... where the attacker provides both the URL and any
    digital certificate that supports that they are who they claim to be.

    there is separate "catch-22" scenario that certification authorities
    are looking at for improving the integrity of the domain name digital
    certificates that they issue. currently they require a lot of
    identification information as to the applicant for the digital
    certificate. they then go thru a time-consuming, costly, and error
    prone processing of cross-checking that the provided information (by
    the digital certificate applicant) matches the information on-file
    with the domain name infrastructure as to the owner of the specific
    domain.

    the proposal is for having domain name owners provide a public key to
    the domain name infrastructure when they register the domain name.
    now the certification authorities can require that digital certificate
    applications be digitally signed. Now the certification authorities
    can do a real-time retrieval of the on-file public key (from the
    domain name infrastructure ... analogous to what they do now when they
    do real-time retrieval of information as to the owner of the domain
    name for matching) ... and use it to validate the digital
    signature. This turns a time-consuming, error prone, and costly
    identification matching process into a much more reliable, simple, and
    less expensive authentication process.

    the "catch-22" is that if the certification authority can do a
    real-time retrieval of the on-file public key for digital certificate,
    then potentially the rest of the world can also ... eliminating
    the need for the digital certificates ... misc. past posts mentioning
    the "catch-22"
    http://www.garlic.com/~lynn/subpubkey.html#catch22

    that can result in transition to certificateless public key operation.
    misc. past posts mentioning certificateless operation
    http://www.garlic.com/~lynn/subpubkey.html#certless

    and reference to old email from 1981 with a suggestion for a
    certificateless public key operation:
    http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
    http://www.garlic.com/~lynn/2006w.html#15 more secure communication over the network
    http://www.garlic.com/~lynn/2006w.html#18 more secure communication over the network

    some number of references to account-based public key operation
    (as opposed to digital certificate public key operation)
    http://www.garlic.com/~lynn/x959.html#aads
     
    Anne & Lynn Wheeler, Jan 2, 2007
    #3
  4. "UKuser" <> (07-01-02 08:42:02):

    > Secondly, why is mixed content so bad (any sites would be great)? I
    > appreciate various elements could be secure/unsecure but how would
    > that pose a risk?


    I'd like to drop a note here. Others have mentioned the performance
    impact coming from SSL. But this is not a problem of SSL itself. It's
    a configuration problem.

    Actually there is nothing wrong with running an entire site through SSL,
    since you can turn on and off authentication and encryption as you like.
    So you would transmit everything authenticated, but not encrypted, and
    you would only encrypt the textual content.

    But since most admins just hit the "Make My Connections Secure (TM)"
    button on their administration web-interface, the bad performance is
    natural. To properly use SSL, you really should have some background
    information about public-key cryptography, and you really should
    configure your HTTPd carefully by hand.

    That also helps exploiting the full potential of SSL. For example, you
    can't just authenticate the server, you can also authenticate the client
    or anything else via a certificate. So no more username/password pairs
    are needed. Users don't need to login manually, they just present their
    certificate, which is straightforward in today's modern browsers.


    Regards,
    E.S.
     
    Ertugrul Soeylemez, Jan 3, 2007
    #4
  5. Ertugrul Soeylemez wrote:

    > Actually there is nothing wrong with running an entire site through SSL,
    > since you can turn on and off authentication and encryption as you like.
    > So you would transmit everything authenticated, but not encrypted, and
    > you would only encrypt the textual content.


    Bad idea. Who decides which part of the content is important to encrypt and
    which is not? You? A program? I doubt that anyone gets it right. That's why
    you should encrypt everything.

    > [snip]


    > That also helps exploiting the full potential of SSL. For example, you
    > can't just authenticate the server, you can also authenticate the client
    > or anything else via a certificate. So no more username/password pairs
    > are needed. Users don't need to login manually, they just present their
    > certificate, which is straightforward in today's modern browsers.


    And without a PKI, this will nullify any security, since the attacker could
    easily impersonate the client.
     
    Sebastian Gottschalk, Jan 3, 2007
    #5
  6. Ertugrul Soeylemez <> writes:
    > That also helps exploiting the full potential of SSL. For example, you
    > can't just authenticate the server, you can also authenticate the client
    > or anything else via a certificate. So no more username/password pairs
    > are needed. Users don't need to login manually, they just present their
    > certificate, which is straightforward in today's modern browsers.


    actually, client authentication/authorization can be done straight
    forwardly using registered public keys and digital signatures w/o
    requiring any digital certificate what-so-ever. misc. past posts
    mentioning certificateless operation
    http://www.garlic.com/~lynn/subpubkey.html#certless

    the first place that became especially evident was when we were
    brought in to do some consulting with this small client/server startup
    that had this technology called SSL and wanted to do payment
    transactions ... for something that has since come to be called
    e-commerce. previous post in this thread:
    http://www.garlic.com/~lynn/2007.html#7 SSL info

    at the time SSL didn't have mutual authentication ... but we required
    it for the payment gateway (the webservers authenticated the payment
    gateway using installed public key ... and the payment gateway
    authenticate the webservers using on-file public keys). The addition
    code had to be added to SSL to do mutual authentication and since it
    was already heavily certificate-based orientation there still were
    digital certificates that were passed back-and-forth ... but in
    actuality ... each authorized webserver had the information about the
    payment gateway preloaded as part of the payment processing software
    .... and the payment gateway had onfile information about each
    authorized webserver. it quickly became strikenly apparent that
    the digital certificates were redundant and superfluous. misc.
    other posts mentioning ssl digital certificates
    http://www.garlic.com/~lynn/subpubkey.html#sslcert

    so the dominant forms of client authentication in the world wide web
    environments are KERBEROS and RADIUS. These started out being
    userid/password. However, both KERBEROS and RADIUS have had
    definitions and implementations were client public keys are registered
    (in lieu of passwords), servers transmit some random information (as
    countermeasure to replay attacks), and the clients (using their
    private key) digitally sign and return the digital signature ... which
    the server than verifies with the onfile public key.

    The original KERBEROS PKINIT (public key) draft initially just
    specified certificateless operation ... but under a great deal
    of lobbying, certificate-mode operation was also added.

    One of the scenarios for various webserver software is that client
    authentication has frequently just been a stub model ... although
    there are plugins for webserver software that provide kerberos and
    radius interfaces for client authentication. In many of these typical
    implementations ... the kerberos and radius implementations are done
    in such a way that it is possible to specify password or digital
    signature operation on a account by account basis ... again
    certificateless operation. misc. past posts about kerberos operation
    http://www.garlic.com/~lynn/subpubkey.html#kerberos
    and radius operation
    http://www.garlic.com/~lynn/subpubkey.html#radius

    sort of the original idea for certificate-mode of operation was that
    there was interaction between two parties that had no prior knowledge
    of each other. it was necessary for the certificates to carry all the
    necessary information. this also sort of gave rise to the x.509
    identity certificates from the early 90s.

    however, by the mid-90s it was realized that x.509 identity
    certificates, typically heavily overloaded with personal information
    represented significant privacy and liability issues. as a result,
    you saw many institutions dropping back to what they called
    relying-party-only certificates ... misc. past posts mentiong
    RPO certificates:
    http://www.garlic.com/~lynn/subpubkey.html#rpo

    the issue here is that an RPO-certificate basically just carries a
    public key and some sort of account number. the relying party, takes
    the account number and retrieves the appropriate account record
    .... where the actual personal information including any authorization
    information is kept. however, since the public key originally had to
    be registered and stored in an account record before any digital
    certificate was issued, it was trivial to show that the relying party
    retrieving the account record can include the registered public key.
    Again, the digital certificate becomes redundant and superfluous.

    basically the kerberos and radius PKI implementations with digital
    certificates typically have done something similar as RPO-certificate,
    the permission/authorization information is stored in an onfile
    account record. if any of the client PKI digital certificates
    authentication operations (kerberos, radius, or roll-your-own) at some
    point have to retrieve any sort of account record as part of
    permissions and authorizations ... it is then trivial to also show
    (again) that the digital certificates are redundant and superfluous.

    The digital certificate actually only has meaninful role ... when the
    server never has to resort to really knowing who the client is and/or
    anything about the client ... other than what is presented in the
    digital certificates. No additional information related to things like
    permissions, authorizations, billing, accounts, etc is required.

    its like anybody with valid digital certificate can log into your
    system and have all permissions regardless of who they are ... and
    there is no userid account record for the system that is required to
    provide any additional information related to the user and/or what the
    user is allowed to do or not do.

    as soon as the process has to resort to any additional information
    (than what is provided in the digital certificate) for doing any
    operation what-so-ever for the client ... then it is trivial to
    show that the digital certificate is redundant and superfluous.
     
    Anne & Lynn Wheeler, Jan 3, 2007
    #6
  7. UKuser

    UKuser Guest

    Hi Sebastian,

    Thanks for the information. You're obviously assuming that an attacker
    can get to the unsecured content and modify it. What would stop an
    attacker accessing files on a secure area as well? If SSL just encrypts
    the communication between the webserver and client, how are the SSL
    files any more secure?

    Thanks

    A

    Sebastian Gottschalk wrote:

    > UKuser wrote:
    >
    > > I'm going to be working with some SSL pages (php) and wondered if there
    > > were any good design/development sites for security tips etc so I miss
    > > out on making the "obvious" blunders - whatever they may be.

    >
    > The obvious blunders are incompetent Root-CA s. You can easily recognize
    > them: If they're claiming to be Root-CA, then they're incompetent.
    >
    > > I've found: http://blogs.msdn.com/ie/archive/2005/04/20/410240.aspx
    > > which is very good and lists two possible problems. Here then is the
    > > newbie question.
    > >
    > > If a form is hosted on a HTTP (non secure) site and points to a HTTPS
    > > in the action tag, does this mean that the page has already made the
    > > SSL connection/handshake?

    >
    > No.
    >
    > > Does the browser recognise the potential for
    > > a HTTPS connection and therefore do the same as if it was a full SSL
    > > page?

    >
    > Yes. However, this won't help if the attacker can modified the unsecure
    > form to transmit the content to somewhere else.
    >
    > > Secondly, why is mixed content so bad (any sites would be great)? I
    > > appreciate various elements could be secure/unsecure but how would that
    > > pose a risk?

    >
    > Simple: The nonsecure content can be modified by an attacker, and such a
    > modified content can also modify/overwrite/extend the secure content.
    >
    > Trivial example: Overwrite an nonsecure CSS stylesheet with "body {
    > display:none; visible: no; content-before:<!-- put your phishing website
    > here -->}"
     
    UKuser, Jan 3, 2007
    #7
  8. UKuser

    UKuser Guest

    Just want to thank everyone for their contributions. I thought
    (incorrectly) this would appear under Sebastians reply.

    A

    UKuser wrote:

    > Hi Sebastian,
    >
    > Thanks for the information. You're obviously assuming that an attacker
    > can get to the unsecured content and modify it. What would stop an
    > attacker accessing files on a secure area as well? If SSL just encrypts
    > the communication between the webserver and client, how are the SSL
    > files any more secure?
    >
    > Thanks
    >
    > A
    >
    > Sebastian Gottschalk wrote:
    >
    > > UKuser wrote:
    > >
    > > > I'm going to be working with some SSL pages (php) and wondered if there
    > > > were any good design/development sites for security tips etc so I miss
    > > > out on making the "obvious" blunders - whatever they may be.

    > >
    > > The obvious blunders are incompetent Root-CA s. You can easily recognize
    > > them: If they're claiming to be Root-CA, then they're incompetent.
    > >
    > > > I've found: http://blogs.msdn.com/ie/archive/2005/04/20/410240.aspx
    > > > which is very good and lists two possible problems. Here then is the
    > > > newbie question.
    > > >
    > > > If a form is hosted on a HTTP (non secure) site and points to a HTTPS
    > > > in the action tag, does this mean that the page has already made the
    > > > SSL connection/handshake?

    > >
    > > No.
    > >
    > > > Does the browser recognise the potential for
    > > > a HTTPS connection and therefore do the same as if it was a full SSL
    > > > page?

    > >
    > > Yes. However, this won't help if the attacker can modified the unsecure
    > > form to transmit the content to somewhere else.
    > >
    > > > Secondly, why is mixed content so bad (any sites would be great)? I
    > > > appreciate various elements could be secure/unsecure but how would that
    > > > pose a risk?

    > >
    > > Simple: The nonsecure content can be modified by an attacker, and such a
    > > modified content can also modify/overwrite/extend the secure content.
    > >
    > > Trivial example: Overwrite an nonsecure CSS stylesheet with "body {
    > > display:none; visible: no; content-before:<!-- put your phishing website
    > > here -->}"
     
    UKuser, Jan 3, 2007
    #8
  9. UKuser wrote:

    > You're obviously assuming that an attacker can get to the unsecured content
    > and modify it.


    That's one of the scenarios SSL is supposed to protect against.

    > What would stop an attacker accessing files on a secure area as well?


    User authentication? Can be done via SSL, but HTTP Digest Authentication
    does this as well. Plaintext passwords are also quite common, but a bad
    idea.

    > If SSL just encrypts the communication between the webserver and client,
    > how are the SSL files any more secure?


    Because "secure" on its own doesn't make any sense, you have to ask "secure
    against which attack vector".
     
    Sebastian Gottschalk, Jan 3, 2007
    #9
  10. Anne & Lynn Wheeler <> writes:
    > however, by the mid-90s it was realized that x.509 identity
    > certificates, typically heavily overloaded with personal information
    > represented significant privacy and liability issues. as a result,
    > you saw many institutions dropping back to what they called
    > relying-party-only certificates ... misc. past posts mentiong
    > RPO certificates:
    > http://www.garlic.com/~lynn/subpubkey.html#rpo


    for a little drift ... these are a couple of posts that draw the
    comparison between some of the current electronic chip passports and
    the x.509 identity certificates from the early 90s.
    http://www.garlic.com/~lynn/aadsm25.htm#46 Flaw exploited in RFID-enabled passports
    http://www.garlic.com/~lynn/aadsm26.htm#0 Flaw in RFID-enabled passports (part 2?)

    using that comparison, then there is the possibility that all personal
    information would be eliminated from the passport chips ... for
    similar privacy and liability reasons that resulted in change-over to
    relying-party-only certificates in the mid-90s (and away from x.509
    identity certificates frequently overloaded with personal information)
    http://www.garlic.com/~lynn/subpubkey.html#rpo

    after having worked on SSL-based infrastructure ... that has since come
    to be called e-commerce ... previous posts in this thread
    http://www.garlic.com/~lynn/2007.html#7 SSL info
    http://www.garlic.com/~lynn/2007.html#15 SSL info

    we had participated in the x9a10 financial standard working group. In the
    mid-90s, x9a10 had been given the requirement to preserve the integrity
    of the financial infrastructure for all retail payments
    http://www.garlic.com/~lynn/x959.html#x959
    http://www.garlic.com/~lynn/subpubkey.html#x959

    it was in this period that we had coined the term certificate
    manufactoring to differentiate the commoningly deployed SSL digital
    certificate infrastructure (of the period) from "real" PKI:
    http://www.garlic.com/~lynn/subpubkey.html#manufacture

    it was also in this period that several people made claims that
    upgrading financial transactions with client/consumer digital
    certificates would bring retail financial transactions in the modern
    era.

    the issue here (as in the passport case) is that credentials and
    certificates are constructs developed for providing trusted
    information for an offline environment. in the 70s, electronic payment
    networks made the transition from the offline environment to the
    online environment ... and supported real-time information regarding
    authentication and authorization. digital certificate-based offline
    paradigm for financial transactions, rather than representing any
    modernization, would result to reverting to pre-70s paradigm.

    it was in this period that we also coined the term "comfort
    certificates" ... the redundant and superfluous use of stale, static
    digital certificates (an offline paradigm construct) in an online
    environment. The "comfort certificates" provided familiarity and
    comfort to mindsets that were stuck in the old fashion offline
    paradigm (which required credentials and certificates to provide
    trusted information distribution) ... and had difficulty making the
    transition to an trusted online integrity paradigm.

    our repeated observations about the offline digital certificate model
    actually regressing effective operation by several decades (rather
    than any modernization) was some of the motivation behind OCSP (online
    certificate status protocol). However, our observation was that it was
    really a rube golberg fabrication ... given any operation ... what is
    more valuable: ... 1) a real time transaction involving real time
    authentication and authorization information ... or 2) a real time
    transaction providing status indication about stale, static digital
    certificate information.

    this was also the period that spawned the infrastructure that enabled
    the "yes card" exploits
    http://www.garlic.com/~lynn/subintegrity.html#yescard

    i.e. adding chips to payment cards for use in retail transactions.
    there were some number of claims that adding the chips even increased
    the vulnerabilities ... compared to a similar magstripe card w/o a
    chip.
     
    Anne & Lynn Wheeler, Jan 3, 2007
    #10
  11. Sebastian Gottschalk <> (07-01-03 04:41:33):

    > > Actually there is nothing wrong with running an entire site through
    > > SSL, since you can turn on and off authentication and encryption as
    > > you like. So you would transmit everything authenticated, but not
    > > encrypted, and you would only encrypt the textual content.

    >
    > Bad idea. Who decides which part of the content is important to
    > encrypt and which is not? You? A program? I doubt that anyone gets it
    > right. That's why you should encrypt everything.


    Yes, you should. But in situations, where this is simply not possible,
    you should at least sign the traffic, which you don't encrypt. That's
    my point.


    > > That also helps exploiting the full potential of SSL. For example,
    > > you can't just authenticate the server, you can also authenticate
    > > the client or anything else via a certificate. So no more
    > > username/password pairs are needed. Users don't need to login
    > > manually, they just present their certificate, which is
    > > straightforward in today's modern browsers.

    >
    > And without a PKI, this will nullify any security, since the attacker
    > could easily impersonate the client.


    No problem. Take the server as the CA. On registration, the user
    chooses a user-name. And instead of a password, they present their
    certificate (implicitly by connecting through SSL) to the server, which
    the server saves and signs. Unless the client's certificate has already
    been used (which would be a clear sign for compromise), the user is now
    logged in, as long as he connects through SSL with that particular
    certificate.

    What is nice about this method is that you can use the same client
    certificate for arbitrarily many sites. You can't do that with
    passwords. You would have to choose a different one for each site.


    Regards,
    E.S.
     
    Ertugrul Soeylemez, Jan 5, 2007
    #11
  12. Ertugrul Soeylemez wrote:

    >>> [SSL client certificates]

    >> And without a PKI, this will nullify any security, since the attacker
    >> could easily impersonate the client.

    >
    > No problem. Take the server as the CA. On registration, the user
    > chooses a user-name. And instead of a password, they present their
    > certificate (implicitly by connecting through SSL) to the server, which
    > the server saves and signs. Unless the client's certificate has already
    > been used (which would be a clear sign for compromise), the user is now
    > logged in, as long as he connects through SSL with that particular
    > certificate.


    This is trivally prone to a man-in-the-middle attack. You really don't
    understand what out-of-bound-authentication is and why it's a necessity?

    > What is nice about this method is that you can use the same client
    > certificate for arbitrarily many sites.


    Nice? This is rather bad, since it reduces security and eliminates privacy.
    Where have you been when MS Passport was cracked over and over again?
     
    Sebastian Gottschalk, Jan 5, 2007
    #12
  13. Sebastian Gottschalk <> (07-01-05 17:21:42):

    > > > And without a PKI, this will nullify any security, since the
    > > > attacker could easily impersonate the client.

    > >
    > > No problem. Take the server as the CA. On registration, the user
    > > chooses a user-name. And instead of a password, they present their
    > > certificate (implicitly by connecting through SSL) to the server,
    > > which the server saves and signs. Unless the client's certificate
    > > has already been used (which would be a clear sign for compromise),
    > > the user is now logged in, as long as he connects through SSL with
    > > that particular certificate.

    >
    > This is trivally prone to a man-in-the-middle attack. You really don't
    > understand what out-of-bound-authentication is and why it's a
    > necessity?


    Taking the server as a CA implies that the clients (need to) have that
    particular CA certificate. No trusted arbitrator is necessary inside of
    the protocol. But there is indeed a need for one, when distributing the
    CA certificate, unless this is applied to a local network, where a
    secure infrastructure is already in place.


    > > What is nice about this method is that you can use the same client
    > > certificate for arbitrarily many sites.

    >
    > Nice? This is rather bad, since it reduces security and eliminates
    > privacy.


    I have a single GPG key pair, with which I sign for multiple email
    addresses. I have a single SSH key pair, which I use to login to a lot
    of sites. According to your statement, this is less secure than using a
    separate key for each site and email address, and my privacy is
    completely lost. Sounds odd, doesn't it?

    Besides the fact that a certificate contains a bit more information,
    what are the privacy implications? Unless the certificate represents
    something like an electronic form of your passport, you decide, what
    goes in there. When the CA decides to sign it, then they do so.
    Otherwise you're free to go elsewhere.

    Now to the security part: A public key, as its name states, is made
    publicly available. If that does reduce security, then what's the point
    in public key cryptography? The authenticator really just needs the
    public key to verify authenticity. A certificate is nothing more than
    an encapsulated public key, together with some informations about its
    holder, and one or more signatures (at least from a CA in the proper
    case).


    > Where have you been when MS Passport was cracked over and over again?


    I really don't care about the diseases of Microsoft implementations.
    Microsoft Passport is not a PKI anyway, so what?


    Regards,
    E.S.
     
    Ertugrul Soeylemez, Jan 6, 2007
    #13
  14. Ertugrul Soeylemez <> writes:
    > Besides the fact that a certificate contains a bit more information,
    > what are the privacy implications? Unless the certificate represents
    > something like an electronic form of your passport, you decide, what
    > goes in there. When the CA decides to sign it, then they do so.
    > Otherwise you're free to go elsewhere.
    >
    > Now to the security part: A public key, as its name states, is made
    > publicly available. If that does reduce security, then what's the point
    > in public key cryptography? The authenticator really just needs the
    > public key to verify authenticity. A certificate is nothing more than
    > an encapsulated public key, together with some informations about its
    > holder, and one or more signatures (at least from a CA in the proper
    > case).


    so you have a client that generates a public/private key pair. the
    client registers the public key with the server/certification
    authority ... the server/ca registers the public key in the server/ca
    database ... then the server/ca generates a digital certificate
    containing the public key and gives a copy of the digital certificate
    to the client..

    now in an authentication operation, the client digital signs
    something, appends the digital certificate and transmits the digital
    signature and digital certificate to the server/ca ... who already has
    a copy of the client's public key on-file.

    since the server/ca already has a copy of the client's public
    key (as part of the registration operation) ... and, in fact,
    the server/ca probably even recorded the original of the client's
    digital certificate. that means the server/ca not only has the
    client's public key as well the client's digital certificate.

    requiring the client to return a copy of the digital certificate to
    the ca/server on each digital signature operation is redundant and
    superfluous ... when the ca/server already has copy of the client's
    public key and typically also has the client's original digital
    certificate (after having sent a copy of the client's digital
    certificate to the client).

    the ca/server would also run much more efficiently if they just used
    the onfile client's public key that they already have to verify the
    client's digital signature ... rather than having to go thru the
    repeated extraneous gorp of verifying the (appended transmitted)
    client digital certificate along with all the related digital
    certificate encoding/decoding magic.

    past posts in this thread:
    http://www.garlic.com/~lynn/2007.html#7 SSL info
    http://www.garlic.com/~lynn/2007.html#15 SSL info
    http://www.garlic.com/~lynn/2007.html#17 SSL info

    as mentioned before ... one of the reasons for the retrenching from
    the early 90s x.509 identity digital certificates to the
    relying-party-only digital certificates in the mid-90s ... was
    eliminating all the extraneous personal information. It isn't so much
    the publication of public key that was the issue ... it was spraying
    personal information all over the place everytime the digital
    certificate was transmitted.

    Reducing the digital certificate to public key and some sort of
    (server) record locator ... is the relying-party-only digital
    certificate
    http://www.garlic.com/~lynn/subpubkey.html#rpo

    however, it is straight-forward to demonstrate that it is much more
    efficient and drastically simpler for the relying party to directly
    retrieve the public key from an online record, eliminating all of the
    client digital certificate gorp ... i.e. certificateless public key
    http://www.garlic.com/~lynn/subpubkey.html#certless

    so comparing simple certificateless digital signature authentication
    to password authentication

    1) well implemented digital signature authentication is immune from
    skimming/evesdropping and replay attacks (impersonation)

    2) typically password scenarios require a unique value for every
    different security domain. the problem is that the same value is
    used for both origination and verification. unique passwords
    are countermeasure for scenarios where one domain can attack
    another (i.e. local garage isp and your online banking or
    your place of business).

    there is huge advantage of using public keys (and digital signatures)
    for authentication ... compared to pins/passwords. this is true
    regardless of whether it is a certificate or certificateless paradigm.

    however, sometimes there is misconception that public keys
    and digital certificates are equivalent.

    digital certificates are mechanism for trusted information
    distribution for the offline enviornment ... somewhat the electronic
    version of letters of introduction/credit from the sailing ship days
    .... when two entities had no prior relations .... and the relying
    party had no way of directly contacting the certifying party.

    However when it becomes abundently evident that the offline paradigm
    digital certificates are redundant and superfluous in an online world
    .... and/or between entities that have established relationship ...
    then it doesn't have to follow that there is no advantage to having
    public key infrastructure (without digital certificates).
     
    Anne & Lynn Wheeler, Jan 6, 2007
    #14
  15. Anne & Lynn Wheeler <> (07-01-05 21:09:35):

    > [bunch of redundant non-information]


    If I ask, how to dispose a car, you explain the construction ideas of
    its fuel tank.


    Regards,
    E.S.
     
    Ertugrul Soeylemez, Jan 7, 2007
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Gavin
    Replies:
    0
    Views:
    552
    Gavin
    May 15, 2004
  2. Olivier PELERIN

    SSL with backend SSL on CSS 11500

    Olivier PELERIN, Aug 30, 2004, in forum: Cisco
    Replies:
    0
    Views:
    3,922
    Olivier PELERIN
    Aug 30, 2004
  3. PeterPan

    Wanted Info on UK-Info, & WebDesign

    PeterPan, Nov 27, 2003, in forum: Computer Support
    Replies:
    3
    Views:
    883
  4. jenny
    Replies:
    0
    Views:
    975
    jenny
    Nov 30, 2006
  5. Replies:
    0
    Views:
    610
Loading...

Share This Page