In SSL We Trust? Not Lately

Discussion in 'Computer Security' started by Anne & Lynn Wheeler, Apr 8, 2010.

  1. In SSL We Trust? Not Lately
    http://www.darkreading.com/blog/archives/2010/04/trust_in_ssl_st.html

    from above:

    In the past two weeks we have seen multiple problems with SSL, which
    is used in our Web browsers to protect the privacy and integrity of
    our electronic transactions. Earlier this week there was a report on a
    digital certificate in Firefox's certificate store that nobody could
    account for.

    .... snip ...

    we had been called in to consult with small client/server startup that
    wanted to do payment transactions and they had invented this technology
    called SSL they wanted to use. As part of applying the technology to
    business process we also did walk thru of these new business operations
    calling themselves "Certification Authorities" ... as well as some
    requirements regarding deployment and use. Almost immediately various of
    the requirements were ignored. Somewhat as a result, very early I coined
    the term "merchant comfort certificates" to describe the situation
    .... i.e. not used to provide security but used to provide a sense of
    comfort. Past posts mentioning SSL ("merchant comfort") certificates
    http://www.garlic.com/~lynn/subpubkey.html#sslcerts


    part of the old extended "merchant comfort certificate" thread ... then
    gets into infrastructure improvements for DNS (because the root of
    issuing SSL certificate is verifying that the domain name certificate
    applicant is the same as registered in the DNS database as the true
    owner of the domain). Part of the issue with the infrastructure
    improvements for DNS could go a long ways towards eliminating the need
    for SSL domain name certificates ... quite a catch22 for the
    Certification Authority industry
    http://www.garlic.com/~lynn/subpubkey.html#catch22

    some recent references:
    http://www.garlic.com/~lynn/2010g.html#10 Gov't coerced Certs thwart SSL/TLS
    http://www.garlic.com/~lynn/2010g.html#14 Gov't coerced Certs thwart SSL/TLS
    http://www.garlic.com/~lynn/2010g.html#29 someone smarter than Dave Cutler
    http://www.garlic.com/~lynn/2010g.html#54 Gov't coerced Certs thwart SSL/TLS
    http://www.garlic.com/~lynn/2010g.html#58 Gov't coerced Certs thwart SSL/TLS
    http://www.garlic.com/~lynn/2010g.html#65 Fraudsters Can Easily Buy SSL Certificates, Researcher Finds
    http://www.garlic.com/~lynn/2010g.html#66 What is the protocal for GMT offset in SMTP (e-mail) header
    http://www.garlic.com/~lynn/2010g.html#74 Unknown SSL credential could imperil Firefox, Mac users

    --
    42yrs virtualization experience (since Jan68), online at home since Mar1970
    Anne & Lynn Wheeler, Apr 8, 2010
    #1
    1. Advertising

  2. Anne & Lynn Wheeler wrote:
    > In SSL We Trust? Not Lately
    > http://www.darkreading.com/blog/archives/2010/04/trust_in_ssl_st.html
    >
    > from above:
    >
    > In the past two weeks we have seen multiple problems with SSL, which
    > is used in our Web browsers to protect the privacy and integrity of
    > our electronic transactions.


    Of course, SSL/TLS is far from being the weakest link in *that* chain.
    It's hardly worth attacking. Why use a MITM attack to grab one credit
    card number at a time, when you can break into someone's database and
    steal a million of them? Why use an active attack at all when a cheap
    phishing scam could get you a nice haul while you do other things?

    > Earlier this week there was a report on a
    > digital certificate in Firefox's certificate store that nobody could
    > account for.


    Except that people accounted for it almost immediately - in less than
    24 hours, in the case of BUGTRAQ. (Francis Litterio asked about it
    2010-03-22 at 12:42 EDT; pointed out what it was for
    on the 23rd at 11:50 EDT.)

    > we had been called in to consult with small client/server startup that
    > wanted to do payment transactions and they had invented this technology
    > called SSL they wanted to use. As part of applying the technology to
    > business process we also did walk thru of these new business operations
    > calling themselves "Certification Authorities" ... as well as some
    > requirements regarding deployment and use. Almost immediately various of
    > the requirements were ignored. Somewhat as a result, very early I coined
    > the term "merchant comfort certificates" to describe the situation
    > ... i.e. not used to provide security but used to provide a sense of
    > comfort. Past posts mentioning SSL ("merchant comfort") certificates
    > http://www.garlic.com/~lynn/subpubkey.html#sslcerts


    Yup. SSL/TLS, in typical B2C online commercial use, is mostly security
    theater. It does increase the work factor for some attacks, if users
    are reasonably knowledgeable and reasonably careful - but most users
    are neither.

    But the same is true of many other aspects of our economic
    infrastructure. Credit card signature panels and CVV2 numbers are
    mostly security theater (as are most things that require a signature),
    as are the chip-and-pin card systems used in Europe. The bogus
    two-factor authentication systems used on many websites are security
    theater. Ditto "Verified by Visa" and similar systems.

    The point is to encourage enough economic activity that the margins
    leave room to cover fraud and still make a profit.

    --
    Michael Wojcik
    Micro Focus
    Rhetoric & Writing, Michigan State University
    Michael Wojcik, Apr 9, 2010
    #2
    1. Advertising

  3. Michael Wojcik <> writes:
    > Of course, SSL/TLS is far from being the weakest link in *that* chain.
    > It's hardly worth attacking. Why use a MITM attack to grab one credit
    > card number at a time, when you can break into someone's database and
    > steal a million of them? Why use an active attack at all when a cheap
    > phishing scam could get you a nice haul while you do other things?


    re:
    http://www.garlic.com/~lynn/2010g.html#79 In SSL We Trust? Not Lately

    several times in early deployment of SSL & what is now called
    "electronic commerce" ... we pointed out that there were no known
    scenarios of actually evesdropping card numbers "in flight" ... and the
    MITM countermeasure was so weak that we coined the term "merchant
    comfort certificates" ... aka it isn't for security ... it is for
    providing a feeling of comfort. The spamming/phishing scenario getting
    people to click on URL taking them to some place ... works whether it is
    HTTP or HTTPS (all the attacker needs is a valid digital certificate and
    possibly a modified proxy where it pairs session to the real website ...
    actually much simpler than creating a duplicate of the real website).
    http://www.garlic.com/~lynn/subpubkey.html#sslcert

    SSL was supposed to provide both an evesdropping countermeasure as well
    as a MITM countermeasure. attackers can actually use a fraudulent
    URL/IP-address that then does some sort of proxy-like operation to the
    real website.
    http://www.garlic.com/~lynn/subintegrity.html#mitm

    Part of the requirements for the original SSL deployment for "electronic
    commerce" was that the end-user understood the relationship between the
    webserver they believed they were talking to and the webserver URL. Then
    the browser SSL code would validate the correspondance between the
    user-entered URL and the webserver contacted. The result was that the
    webserver that the user thot they were talking to, was in-fact, the
    webserver they were talking to.

    The merchant webservers almost immediately violated that requirement.
    They found that HTTPS/SSL cut their thruput by 90-95% and so they
    dropped back to no longer having HTTPS/SSL for the initial webserver
    contact ... but just for the clicked-on checkout/pay button. The
    HTTPS/SSL was no longer being used to validate the session from a user
    provided URL ... but for a URL provided by an unvalidated website. The
    net result was that HTTPS/SSL just provided validation that the whatever
    the webserver claimed to be (by the URL it provided ... not the user)
    was the webserver that it was. This creates an enormous disconnect in
    the security model.

    In the mid-90s, somewhat as result of doing the initial "electronic
    commerce" stuff ... we were invited to participate in the x9a10
    financial standard working group ... which had been given the
    requirement to preserve the integrity of the financial infrastructure
    for *ALL* retail payments ... which resulted in the x9.59 financial
    retail payment standard (for *ALL* retail payments, aka point-of-sale,
    attended, unattended, card-present, internet, low-value, high-value,
    transit turnstyle, debit, credit, ach, stored-value, gift-card, aka
    *ALL*).
    http://www.garlic.com/~lynn/x959.html#x959

    In the same time-frame there was various other organizations proposing
    some internet specific payment specifications. Many of these had
    enourmous cryptography overhead ... much, much larger than SSL ... but
    effectively provided no additional benefit (over what SSL already
    provided). As a result such internet-specific specifications ... with
    the enormously greater overhead and providing no additional benefit ...
    made little headway against the already established SSL convention.
    some past posts referencing the enormous bloat (processing and payload
    size 100 times that of underlying payment transaction)
    http://www.garlic.com/~lynn/subpubkey.html#bloat

    we were also tangentially involved in the cal. state data breach
    notification legislation. we had been brought in to help wordsmith
    the cal. state electronic signature legislation ... some past posts
    http://www.garli.com/~lynn/subpubkey.html#signature

    some of the parties were also heavily involved in privacy issues and had
    done in-depth public privacy surveys and found the number one issue was
    identity theft ... a big portion of that was fraudulent financial
    transactions as a result of data breaches. Nothing seemed to being done
    about the problem, so they seemed to feel that the publicity from the
    mandated notifications might improve the situation.

    However, earlier in the x9a10 financial standard work we had done
    detailed, end-to-end threat & vulnerability studies of the different
    environments. Some of the ways we attempted to describe the current
    paradigm:

    * "dual-use vulnerability"; in the current paradigm, the knowledge of
    the account number may be sufficient to perform a fraudulent transaction
    (effectively authentication, as such it needs to be kept confidential
    and never divulged anywhere) ... while at the same time the account
    number needs to be readily available for a large number of business
    processes. The opposing/conflicting requirements (never divulged and at
    the same time readily available) has led to comments that even if the
    planet was buried under miles of information hiding encryption, it still
    couldn't prevent information leakage.

    * "security proportional to risk"; in the current paradigm, the value of
    the information (for business process) to the merchant is the profit on
    the transaction (possibly a couple dollars) and the value of the
    information (for business processes) to the processor can be a few cents
    per transaction ... while the value of the information (for
    authentication) to the crooks can be the credit limit and/or account
    balance (frequently 100 times or more, larger), as a result, the crooks
    may be able to outspend by 100 times (attacking the infrastructure) as
    the merchants/processors can spend (defending the infrastructure).

    so in x9.59 standard, we slightly tweaked the current paradigm to
    eliminate the dual-use vulnerability ... which also eliminates the data
    breach, skimming, evesdropping, havesting, etc threats (i.e. crooks no
    longer have the prospect of fraudulent financial transactions as
    motivation for such activity; crooks can still perform such activity, it
    just doesn't provide the fraudulent financial return).

    now since, the major use of SSL in the world today is hiding payment
    transactions details ... which is no longer necessary with x9.59
    financial standard ... it also eliminates the major use of SSL.

    now there were some interesting barriers to getting x9.59 deployed
    .... some of which are discussed in recent post:
    http://www.garlic.com/~lynn/2010g.html#21 Should the USA Implement EMV?

    --
    42yrs virtualization experience (since Jan68), online at home since Mar1970
    Anne & Lynn Wheeler, Apr 9, 2010
    #3
  4. Michael Wojcik <> writes:
    > But the same is true of many other aspects of our economic
    > infrastructure. Credit card signature panels and CVV2 numbers are
    > mostly security theater (as are most things that require a signature),
    > as are the chip-and-pin card systems used in Europe. The bogus
    > two-factor authentication systems used on many websites are security
    > theater. Ditto "Verified by Visa" and similar systems.


    re:
    http://www.garlic.com/~lynn/2010g.html#79 In SSL We Trust? Not Lately
    http://www.garlic.com/~lynn/2010g.html#84 In SSL We Trust? Not Lately

    early magstripe were subject to counterfeit cards by just using normal
    credit card account number formulae. the secure hash strategy took
    bin-level shared secret, encoding the information, truncated and added
    it to the magstripe (as countermeasure to simple generation counterfeit
    magstripe credit card).

    wiki discussion of magstripe:
    http://en.wikipedia.org/wiki/Magnetic_stripe_card

    including mentioning that magstripe standard was managed out of los
    gatos lab for serveral years.

    note that this wasn't done for magstripe debit cards ... since the PIN,
    2-factor authentication ... acted as countermeasure to lost/stolen card
    as well as counterfeit magstripe using account number formulae.

    in the past decade this resulted in some press notices claiming debit
    cards were less secure than credit cards ... but it was somewhat the
    associations enabling their credit card networks for debit card
    operation with "signature" debit (as growth in credit card use started
    to drop off and increase in debit cards).

    the associations then could charge interchange fees for "signature"
    debit ... similar to what was being charged for credit card transactions
    (and the transactions would flow over the association networks at all).
    the issue was that the debit cards lost their two-factor authentication.
    Now these debit cards used in "signature" debit mode became vulnerable
    to both lost/stolen card as well as counterfeiting cards using simple
    account number formulae (and the opportunity to have press items
    claiming magstripe debit cards were less secure than credit cards).

    The secure hash strategy was attactive to the associations ... since
    they could collect a repository of the bin-level shared secrets and
    provided added-value standin (being able to validate the magstripe and
    perform stand-in autherization if the backend financial institution went
    offline). The shortcoming in the secure hash magstripe information was
    that it was static data ... and became subject to skimming attacks
    (starting several decades ago) ... where crooks would create countefeit
    magstripes by recording complete data from existing magstripes.

    as previously mentioned, the x9a10 did detailed, end-to-end thread &
    vulnerability studies of most of these characteristics as part
    of coming up with the x9.59 financial standard
    http://www.garlic.com/~lynn/x959.html#x959

    recent thread discussing several of these items:
    http://www.garlic.com/~lynn/2010d.html#17 Chip and PIN is Broken!
    http://www.garlic.com/~lynn/2010d.html#24 Cambridge researchers show Chip and PIN system vulnerable to fraud
    http://www.garlic.com/~lynn/2010d.html#25 Cambridge researchers show Chip and PIN system vulnerable to fraud
    http://www.garlic.com/~lynn/2010d.html#47 Industry groups leap to Chip and PIN's defence
    http://www.garlic.com/~lynn/2010f.html#19 Should the USA Implement EMV?
    http://www.garlic.com/~lynn/2010f.html#25 Should the USA Implement EMV?
    http://www.garlic.com/~lynn/2010f.html#26 Should the USA Implement EMV?
    http://www.garlic.com/~lynn/2010f.html#27 Should the USA Implement EMV?
    http://www.garlic.com/~lynn/2010f.html#30 Should the USA Implement EMV?
    http://www.garlic.com/~lynn/2010f.html#41 Should the USA Implement EMV?
    http://www.garlic.com/~lynn/2010f.html#44 Can't PIN be mandated in normal POS machines ? to avoid Losses / Frauds / NPA's ?
    http://www.garlic.com/~lynn/2010g.html#21 Should the USA Implement EMV?

    --
    42yrs virtualization experience (since Jan68), online at home since Mar1970
    Anne & Lynn Wheeler, Apr 9, 2010
    #4
  5. Anne & Lynn Wheeler wrote:
    >
    > so in x9.59 standard, we slightly tweaked the current paradigm to
    > eliminate the dual-use vulnerability ... which also eliminates the data
    > breach, skimming, evesdropping, havesting, etc threats (i.e. crooks no
    > longer have the prospect of fraudulent financial transactions as
    > motivation for such activity; crooks can still perform such activity, it
    > just doesn't provide the fraudulent financial return).


    Agreed. And since there are other well-established, more-lucrative,
    lower-cost online criminal enterprises (such as various extortion
    rackets), there's little incentive for criminals to try to develop new
    profitable attacks against x9.59.

    > now since, the major use of SSL in the world today is hiding payment
    > transactions details ... which is no longer necessary with x9.59
    > financial standard ... it also eliminates the major use of SSL.


    And most of the remaining uses of SSL/TLS are in situations where it's
    easier to deploy properly and more effective, because there's a
    preexisting relationship among the parties - things like securing
    sensitive traffic within a corporation.

    Though from my experience even there many organizations remain baffled
    by PKI until they bite the bullet and get someone properly trained on
    the subject, whether through training or hiring.

    (And there are other options for these applications, too, such as IPSec.)

    --
    Michael Wojcik
    Micro Focus
    Rhetoric & Writing, Michigan State University
    Michael Wojcik, Apr 16, 2010
    #5
  6. Michael Wojcik <> writes:
    > And most of the remaining uses of SSL/TLS are in situations where it's
    > easier to deploy properly and more effective, because there's a
    > preexisting relationship among the parties - things like securing
    > sensitive traffic within a corporation.
    >
    > Though from my experience even there many organizations remain baffled
    > by PKI until they bite the bullet and get someone properly trained on
    > the subject, whether through training or hiring.


    re:
    http://www.garlic.com/~lynn/2010h.html#1

    in the mid-90s the certification authority PKI industry had business
    case of $20B annum ... that the financial industry would pay $100/annum
    for every one of their account holders. it never happened but as
    it was dwiddling away ... we visited a large financial institution
    with a proposal for a certificateless digital signature authentication
    infrastructure
    http://www.garlic.com/~lynn/subpubkey.html#certless

    they were in the process of winding down a $50m PKI pilot and it looked
    like the participants were just days away from looking for other
    employment. The issue was that the certification authority industry
    wanted the financial institution to send them a account database with
    their 20m account holders, and the certification authority operation
    would munge the account information into digital certificates and only
    charge $100 per ... (aka $2B). When the upper executives of the
    financial institution was presented with the prospect of that $2B
    payment (for the certification authority operation re-arranging the bits
    from each account record and calling it a digital certificate), they
    canceled the whole thing.

    we demonstrated how the public key already in each account record would
    be sufficient for authenticating digitally signed transactions ... w/o
    requiring (the cost and/or overhead of) an associated digital
    certificate.

    the other place that it blew apart was proposal for payment
    transactions. we had been invited into the x9a10 financial standard
    working group in the mid 90s ... which had been given the requirement to
    preserve the integrity of the financial infrastructure for all retail
    payments (in part after having done this stuff now referred to as
    "electronic commerce" with SSL). Part of the effort including detailed,
    end-to-end analysis of the various environments. The result was the
    x9.59 financial transaction that can be authenticated with a digital
    signature w/o requiring a digital certificate to be appended to the
    transaction.

    There were some othere work on payment protocol specifications in the
    period that were strictly PKI, digital certificate oriented ... but we
    easily demonstrated 1) the digital certificate was redundand and
    superfluous in the payment transactions, 2) it represented a redundant
    and superfluous payload bloat of a factor of 100 times (i.e. an appended
    digital certificate increased the typical payment transaction payload by
    100 times), and 3) processing the redundant and superfluous digital
    certificate increased processing bloat by a factor of 100 times.
    http://www.garlic.com/~lynn/subpubkey.html#bloat

    Part of the x9 financial standard body ... recognizing the enormous
    payload bloat of the redundant and superfluous digital certificates
    started a standards effort for "compressed" digital certificate ...
    with an objective of getting the redundant and superfluous payload bloat
    down to possibly only 5-10 times. I took their approaches and showed
    how the digital certificate could be reduced to zero bytes ... then,
    instead of advicating a certificateless operation ... could mandate
    a PKI/certificate based payment operation with appended zero-byte
    digital certificates.

    I had been familar with Kerberos operation at Project Athena (being part
    of the corporate people that would come in for periodic review of Projec
    Athena activity) ... and wrote a spec for a certificateless-based
    PKINIT operation (i.e. digital signature authentication w/o PKI and w/o
    digital certificates) in lieu of passwords:
    http://www.garlic.com/~lynn/subpubkey.html#kerberos

    then there was heavy pressure put on PKINIT to also included
    specification for a PKI-mode (digital certificate) of operation. Some
    time later, the person claiming responsibility for getting PKI-mode
    specification in PKINIT Kerberos RFC ... invited me to give a talk on
    "naked key" (aka certificateless operation), mentioning that he finally
    realized that PKI-mode was redundant and superfluous in the Kerberos
    environment.

    misc. past posts mentioning SSL digital certificates
    http://www.garlic.com/~lynn/subpubkey.html#sslcert

    --
    42yrs virtualization experience (since Jan68), online at home since Mar1970
    Anne & Lynn Wheeler, Apr 16, 2010
    #6
  7. Michael Wojcik <> writes:
    > Agreed. And since there are other well-established, more-lucrative,
    > lower-cost online criminal enterprises (such as various extortion
    > rackets), there's little incentive for criminals to try to develop new
    > profitable attacks against x9.59.


    re:
    http://www.garlic.com/~lynn/2010h.html#1 In SSL We Trust? Not Lately
    http://www.garlic.com/~lynn/2010h.html#25 In SSL We Trust? Not Lately

    the biggest threat/vulnerability are the data breaches (data at rest,
    primarily transaction databases needed as part of normal payment
    business processes) ... then being able to use the information obtained
    from fraudulent transactions. A big issue in x9.59 financial standard
    was no longer needing to hide such information as part of countermeasure
    to (identity theft, account fraud) fraudulent transactions. This
    eliminated the threat against such databases (didn't do anything about
    crooks being able to get at the data ... just eliminated the financial
    fraud motivation for crooks to do so). A side effect was it eliminated
    hiding account number and transaction information anywhere ... including
    the major use of SSL in the world today ... hiding transaction details
    transmitted thru the internet as part of "electronic commerce".

    One of the issues is that in the current account fraud scenarios ... the
    financial institutions are able to charge off the fraud against the
    merchants (there is some claim that interchange fees are structured in
    such a way that there is significant profit from these interchange
    fees). eliminating nearly all such account fraud could result in
    drastically lowering these interchange fees (and potentially a big hit
    to financial institution bottom line).

    There is also the prospect that if the "account fraud" low hanging fruit
    were eliminated ... the crooks would switch to form of identity fraud
    involved with fraudulently opening new accounts. There are gov. mandates
    related to "know your customer" with regard to opening accounts ... and
    the cost is strictly born by the financial institution (no offloading
    interchange fees onto merchants to cover the costs). There was some
    report that significant percentage of such activity currently involves
    "synthetic" identities ... where there isn't even a real person involved
    that can be held liable to cover the fraud.

    misc. recent posts mentioning interchange fees:
    http://www.garlic.com/~lynn/2010.html#70 Post Office bank account 'could help 1m poor'
    http://www.garlic.com/~lynn/2010.html#98 Korean bank Moves back to Mainframes (...no, not back)
    http://www.garlic.com/~lynn/2010b.html#86 Oldest Instruction Set still in daily use?
    http://www.garlic.com/~lynn/2010d.html#21 Credit card data security: Who's responsible?
    http://www.garlic.com/~lynn/2010f.html#44 Can't PIN be mandated in normal POS machines ? to avoid Losses / Frauds / NPA's ?
    http://www.garlic.com/~lynn/2010g.html#21 Should the USA Implement EMV?

    --
    42yrs virtualization experience (since Jan68), online at home since Mar1970
    Anne & Lynn Wheeler, Apr 16, 2010
    #7
    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. Olivier PELERIN

    SSL with backend SSL on CSS 11500

    Olivier PELERIN, Aug 30, 2004, in forum: Cisco
    Replies:
    0
    Views:
    3,596
    Olivier PELERIN
    Aug 30, 2004
  2. Daniel

    Wierd Problems Lately

    Daniel, Apr 22, 2004, in forum: Computer Support
    Replies:
    10
    Views:
    698
    myhelpdesk.org
    Apr 22, 2004
  3. o. phooey
    Replies:
    0
    Views:
    952
    o. phooey
    Jan 8, 2005
  4. Linønut

    What about COLA lately, huh?

    Linønut, Jan 30, 2005, in forum: Computer Support
    Replies:
    1
    Views:
    436
    Warrior
    Jan 30, 2005
  5. jenny
    Replies:
    0
    Views:
    922
    jenny
    Nov 30, 2006
Loading...

Share This Page