Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Electronic Frontier Foundation Security The Internet IT

Thousands of SSL Certs Issued To Unqualified Names 128

Trailrunner7 writes "The recent attack on Comodo and several of its associated registration authorities has spurred quite a bit of re-examination of the way that the Web's certificate authority infrastructure works--or doesn't. One interesting result of this work is that the folks at the Electronic Frontier Foundation have discovered that there are more than 37,000 legitimate certificates issued by CAs for unqualified names such as 'localhost,' or 'Exchange,' a practice that could simplify some forms of man-in-the-middle attacks. 'Although signing "localhost" is humorous, CAs create real risk when they sign other unqualified names. What if an attacker were able to receive a CA-signed certificate for names like "mail" or "webmail?"' Such an attacker would be able to perfectly forge the identity of your organization's webmail server in a "man-in-the-middle" attack!'"
This discussion has been archived. No new comments can be posted.

Thousands of SSL Certs Issued To Unqualified Names

Comments Filter:
  • How is this new? People have been using internal server names (fully qualified and not) for a long time.

    In fact, Microsoft Exchange "best practices" state you should be using the unqualified server name as one of the SAN entries in the SSL cert.

    • Re:No news here (Score:5, Informative)

      by 6031769 ( 829845 ) on Wednesday April 06, 2011 @08:46AM (#35732328) Homepage Journal

      It is new because you would issue a cert for the internal host from your own internal CA. In this case a remote, third-party, seemingly trusted CA has issued a cert for an unqualified host. That's a massive difference and a huge cause for concern.

      • Or, maybe you just get a real certificate issued so you don't have issues when...say...the CEO uses his iPhone or other mobile device internally.
        • by Spad ( 470073 )

          Sounds like the ideal reason to be using an internal CA to me.

          • To avoid "this is an un-trusted root CA", you should use a public cert.

            Is it better to setup the cert properly to not give errors, or teach your users to ignore them?

            • by Spad ( 470073 )

              I'd rather teach users to get IT to install our internal CA certs onto their devices before they'll connect so that all the other internal services signed by our CA will work correctly as well.

              Of course, we could just pay some "trusted" chimps for a wildcard cert for our internal domain, but having our own certificates with direct control over them and the ability to issue whatever we need when we need it is somewhat preferable.

            • by bsDaemon ( 87307 )

              You know you can add your internal CA to the trust chain and take care of the problem without having to abuse the system, right?

            • by Sloppy ( 14984 )

              "set up the cert properly" means to tell the mobile device about your CA.

            • by kasperd ( 592156 )

              Is it better to setup the cert properly to not give errors, or teach your users to ignore them?

              If you want nonstandard certificates, you should setup your own internal CA and add that CA as trusted on the devices where you need it. Devices where you cannot add a CA shouldn't be using SSL to access unqualified hostnames. In those cases get a certificate for the fully qualified hostname, and configure the device to use that.

    • by snsh ( 968808 )
      Our organization used to get wildcard SSL certs from Digicert for our internal AD domain. It was great for a while - we could enable SSL on internal servers without getting a browser warning and without having to set up our own CA/PKI. But Digicert recently pulled the plug and switched us over to SAN certs. They said the CA forum doesn't allow members to issue wildcard certs anymore for .local type domains.

      I don't quite understand what difference it makes.
      • by Anonymous Coward

        Because .local is a valid TLD that could be used in the future. Current MS advice is that your domain should be of the form corp.example.com where example.com is any domain you legitimately own.

    • by kasperd ( 592156 )

      In fact, Microsoft Exchange "best practices" state you should be using the unqualified server name as one of the SAN entries in the SSL cert.

      A widely trusted CA shouldn't issue certificates for unqualified hostnames. It is a bad practice. And if a document calls a bad practice for a best practice, I'll question the validity of said document.

      However, I think the main target for criticism should be the SSL clients. When a client access a domain name that is not fully qualified, it should expand it to a ful

      • by mvdwege ( 243851 )

        In fact, Microsoft Exchange "best practices" state you should be using the unqualified server name as one of the SAN entries in the SSL cert.

        A widely trusted CA shouldn't issue certificates for unqualified hostnames. It is a bad practice. And if a document calls a bad practice for a best practice, I'll question the validity of said document.

        Wouldn't be the first time MS has a very 'interesting' interpretation of best practice. Remember how long it took for Exchange to stop using 'accept-then-bounce' inste

        • Wouldn't be the first time MS has a very 'interesting' interpretation of best practice. Remember how long it took for Exchange to stop using 'accept-then-bounce' instead of outright rejecting the SMTP session for an unknown recipient?

          Remember though the reasoning for that - rejecting immediately allows for a reasonably high-speed dictionary attack to harvest the email addresses in the organisation. Remember also the timing of that decision - the 90's, not the late noughties. For example, consider the following approach:

          • Connect to mail server
          • Attempt to send to a dozen common names - "Bob@domain", "Jim@domain" - if any succeed, assume the email format is FirstName@domain; use dictionary of first names to harvest addresses
          • Attempt to send
          • by mvdwege ( 243851 )

            Stop being an apologist.

            1. Spammers don't use dictionary attacks. They just throw a purchased list of addresses at your mailserver.
            2. In the nineties 'accept-then-bounce' might have been acceptable, but this behaviour was default until the previous version of Exchange, when rejecting already was best practice for almost a decade.

            There is no excuse for this behaviour.

            Mart

          • by kasperd ( 592156 )

            Remember though the reasoning for that - rejecting immediately allows for a reasonably high-speed dictionary attack to harvest the email addresses in the organisation.

            This is a terrible reasoning. Yes, it does increase the resource usage for dictionary attacks a bit. However, it increases the resource usage for the server even more. In addition it causes innocent bystanders to be flooded with bouncing messages.

            If you want to slow down somebody scanning for valid addresses, then just delay the responses to

  • by Anonymous Coward

    Software should automatically reject certificates for unqualified names, even if properly signed.

    • That has the potential for ruining plenty of intranet applications, which can also be SSL protected.
      • by eggled ( 1135799 )
        Intranets can run their own CAs - that's the Right Way to do it, not to issue a public cert for a private domain.
        • Read the post I replied to - his argument was that software, i.e. browsers, should reject properly signed certificates if the domain signed for is unqualified. Thats different to your argument, which I agree with, as running an internal CA would not negate the original suggested remedy.
          • by eggled ( 1135799 )
            Righto - I misread his as the CAs should reject certs for unqualified domains. But then, how can a browser determine unqualified vs. qualified? The DNS server is the authoritative record of domains, so unless you override to an external DNS server, you are not going to impact intranet software.
            • A browser can already tell the difference between qualified and unqualified - it has nothing to do with DNS itself, and everything to do with the presented domain. "myhost" is unqualified, and "myhost.example.com" is qualified - it doesn't matter if "example.com" exists in the wider DNS system, thats not even checked.

              Because you cannot advertise unqualified domains on the wider DNS system, its typically called the intranet zone, and IE in particular uses it to raise the trust level (for example IE may p
              • by arth1 ( 260657 )

                A browser can already tell the difference between qualified and unqualified - it has nothing to do with DNS itself, and everything to do with the presented domain. "myhost" is unqualified, and "myhost.example.com" is qualified - it doesn't matter if "example.com" exists in the wider DNS system, thats not even checked.

                Sorry, but no.
                Say you're on domain "foo.com" and connect to "myhost.example.com" and "myhost.example.company".
                The former is a FQDN, but the latter is an unqualified address, which will (hopefully) take you to myhost.example.company.foo.com.

                How do you propose the browser tell the difference between the two without asking a DNS server for SOA records?

                • by DarkOx ( 621550 )

                  The trouble is the lusers have gotten used to thinking that 'foo.com' is the proper way to type an address, when they want 'foo.com.'. The browser can try foo.com and then its going to try foo.com.{something from my domain search suffice list}..

                  • The trouble is the lusers have gotten used to thinking that 'foo.com' is the proper way to type an address, when they want 'foo.com.'. The browser can try foo.com and then its going to try foo.com.{something from my domain search suffice list}..

                    And this neatly demonstrates how the "domain escalation" approach would work for certificates.

                    When the browser is provided with https://foo/uri [foo], it will use the configured DNS suffixes to find the server and then use the same DNS suffix to confirm that the connection should be trusted. So if you have mydomain.com. and mydomain.net. as your DNS suffixes, and foo resolves in mydomain.net., then the certificate must contain foo.mydomain.net. to be accepted.

                    Mind you I haven't programmed the sockets API so I don

                    • by arth1 ( 260657 )

                      That would break domain hosting.
                      The same machine that hosts company1.com also hosts company2.net and company3.org

                      Of course, the web servers should be smarted and present, if present, a certificate that matches the Host: line in the HTTP request, and not have a static certificate.

                      Anyhow, back to the original post, yes, non-fully-qualified certificates are both legal and have their use. Consider a network that isn't Internet, with its own DNS root servers, for example. If a customer wants a certificate for

                    • by Richy_T ( 111409 )

                      The certificate is used before the Host: header is sent. There are some fixes in the works for this.

  • by RichMan ( 8097 ) on Wednesday April 06, 2011 @08:44AM (#35732290)

    These are not names the CA should be issuing. The only reason for issuing them is greed.

    Make the CA aware that should any illegal activity be done using unqualified names that the CA will held legally responsible.
    Watch the unqualified names disappear overnight.

    • Mod Parent Up.

      Typically considerations for setting up an Exchange 2007 / 2010 CAS is to have a UCC cert that contains both the qualified and unqualified name of the CAS server (or CAS server array). This is to prevent Outlook from throwing a cert error when accessing the server internally.

      While I can't speak to the security implications of such certificates, I can say that this is most certainly not something "controversial" that the SSL providers are doing, it's simply meeting a legitimate customer need.

      • by Loether ( 769074 )

        It is possible for an internal DNS server to resolve your mail.example.com to your local 10.x.x.x inside and let your external DNS tell the outside world the external address. If you are a very small shop and don't want to set up an internal dns server you could even just modify the host file on the boxes that need to access the internal servers.

      • by Spad ( 470073 )

        It's not actually an issue with 2010 any more as you should be specifying FQDNs for the RPCClientAccessServer values on your databases and Outlook will pull the necessary information out of AD when setting up new mail profiles.

      • by h4rr4r ( 612664 )

        You're doing it wrong. This is not a legitimate need, this is folks doing it wrong.

      • by sjames ( 1099 )

        The problem is that the whole system was rigged to keep pointing back to "pay a CA for a cert".

        In a system designed for security first, a server could easily have multiple identities, each supported by an independent cert (The web has finally grown that appendage in the form of SNI). The internal name of an exchange server would be backed by an internal Cert signed by the company's internal CA (with it's key installed on all employee machines) and the external name would be backed by a public cert signed by

        • Of course, any cert would be usable to sign another cert so that example.com could use it's example.com cert (signed by a generally recognized CA) to sign their own cert for api2.example.com. Validation would be a matter of following the signatures until you get to a known and trusted cert. But we couldn''t allow that since it would conflict with "pay a CA for a cert" on the api2 site.

          Uh, what? The reason that doesn't work is nothing to do with "pay a CA for a cert". The reason that doesn't work is that it would completely break the trust model. What you're suggesting would allow a criminal to obtain a certificate for dodgy-site.com (legitimately, since you believe CAs should not be allowed to verify identity and all that stuff because it's "just profiteering"), and use that to sign a cert for bankofamerica.com. Voila, instant MitM.

          Essentially, your idea is foolish and ill conceived.

          • by sjames ( 1099 )

            The default level of trust would be the least trusted in the chain. Presumably, dodgy-site.com would be trusted only to sign subdomains of dodgy-site.com. That is, you trust that they really are dodgy-site.com because a CA you trust says so. That doesn't mean you believe they are conscientious enough to verify others identity for you. If you know and trust dodgy-site.com, feel free to make their cert a trusted introducer in your browser.

            I never said CAs shouldn't be allowed to verify identity anywhere. The

    • Making a corporation legally responsible for its action is like striking at water with a sword. They'll pay the fine, and the executives will still swim in the money.

    • by Sloppy ( 14984 )

      Make the CA aware that should any illegal activity be done using unqualified names that the CA will held legally responsible

      A certification is a statement of opinion. (And furthermore, it is a statement by a complete stranger who has no relationship with you and owes you jack shit.) The sooner we learn this, the sooner we will start to work on real solutions to the problems (i.e. switch to OpenPGP). If you charge CAs with complicity, you are just legitimizing the flawed idea behind our current CA infrast

      • The funny part about your post is that you think PGP doesn't suffer from the exact same set of problems, AND a whole bunch of others that make it absolutely useless to normal people who don't want to be bothered with the fact that it was designed and meant to be used by a bunch of geeks trading keys.

        You can't get through life if you trust no one, you'll die of starvation in your home. I have no urge to personally meet all the people I communicate with regularly in order to exchange keys, nor do I have any

        • by Sloppy ( 14984 )

          The funny part about your post is that you think PGP doesn't suffer from the exact same set of problems

          It doesn't suffer from the problem, because it's based on accepting the idea that you're never fully sure. That is how real life works. Some people are confident that their government never makes mistakes and issues ID to the wrong people, combined with a personal confidence that they are very good at spotting fake IDs. And some people aren't sure about both of those things at all, so they want to see t

      • A certification is a statement of opinion. (And furthermore, it is a statement by a complete stranger who has no relationship with you and owes you jack shit.)

        The same can be said about passports and other government id papers. Does the border guard personally know the guy who issued you your passport? No? But yet he trusts it.

      • by Velex ( 120469 )

        (And furthermore, it is a statement by a complete stranger who has no relationship with you and owes you jack shit.)

        I know I'm going to get modded to hell for suggesting this, but why aren't governments in the business of issuing certs? Governments already issue DBAs and IDs, so why wouldn't it be ideal for them to issue the digital equivalent?

    • Most browser have a set of criteria for certificate inclusion. One of these is typically an independent audit of their practices. I'd suggest that Mozilla should immediately drop all of these CAs, and require a $100,000 recertification if they wish to be included again. Their customers will then complain that, in between now and the time that they completed the recertification, all of their customers got scary warning messages. Gives a strong incentive for CAs not to do this kind of thing again.

    • by guruevi ( 827432 )

      Why not? If you set up your own CA you can issue any name you want as well, I can issue hotmail.com or fbi.gov. SSL certificates are NOT meant to identify a website, they are merely there to secure the link between a server and a client. When people (and browser makers) understand that, we will be quite a bit further.

      • "Your own CA" won't be trusted by browsers. SSL is intended to verify that when you create a connection to 'hotmail.com' the machine on the other end is in fact hotmail.com. Merely encrypting the connection does nothing if I can pretend to be hotmail.com and record your username/password.

        The problem is that the browsers trust CAs which are unscrupulous.
  • by fuzzyfuzzyfungus ( 1223518 ) on Wednesday April 06, 2011 @08:47AM (#35732340) Journal
    Obviously, the notion that CAs are fundamentally broken, dubiously competent, and somewhat parasitic is bad for business and therefore can be rejected out of hand.

    Therefore, I propose the following: All browsers shall be required to stop trusting those inexpensive standard SSL certs, as well as certs issued by budget CAs. 'Extended Validation' certs will now be baseline, with prices remaining unchanged, and two new levels of verification will be added:

    'Extended Validation: Pinky Swear!'(indicated by a green background with two interlocking pinky fingers) will have the same standards as 'EV'; but with the additional promise that we had the work experience kid, or a script, whichever is cheaper, check that the certificate request wasn't made from a hotmail account.

    'Double-Secret Extended Validation'(icon TBA, pending negotiations with film rightsholders) is so secure that we can't even tell you the process by which we verify applications; but it is super secure.

    This should solve all CA related trust issues.
    • Comment removed based on user account deletion
      • by DrXym ( 126579 )
        I'd like to see self generated certs where the signature is a PGP key. Want to know if you can trust the cert? Look at the PGP web of trust. It should be quite feasible.

        These kinds of certs would be more than adequate for individuals, small orgs and whatnot who want the security of a cert without paying a tax to a CA just so they can bless the cert with virtually worthless "trust".

        I don't understand why the likes of Firefox / OpenSSL / GnuPG and other vested interests in the open source movement aren't

        • I don't understand why the likes of Firefox / OpenSSL / GnuPG and other vested interests in the open source movement aren't pushing for a free model for certification which cuts the CAs out of the loop, at least for some kinds of certs.

          Indeed. Especially since there is a free CA around: CaCERT [cacert.org].

          Yes, they failed an audit. But the only reason why they failed it was that they were doing it honestly. Many other CAs which are currently accepted in Firefox would fail the same kind of audit, but they are smart enough not to submit to one.

          • by DrXym ( 126579 )
            CaCERT is a brave attempt to free up the web, but it's constrained by it's need to be seen as trustworthy in order to bestow trust. And in order to do that it has to force registrants to jump through hoops. In CaCERT's case if I want a cert I have to present my government papers to somebody in their web of trust. And I have to do it every 2 years. For what purpose?

            The whole system also has a chilling effect on private communication with sites not using a cert who potentially could and should. I believe th

            • by heypete ( 60671 )

              In CaCERT's case if I want a cert I have to present my government papers to somebody in their web of trust. And I have to do it every 2 years. For what purpose?

              Actually, you need only show your identity documents to someone in their web of trust once. The identity validation is good "for life", and is associated with your cacert account. The certificates issued by cacert are valid for a maximum of two years, after which time one can get fresh certs (indeed, one can get certs revoked and new ones issued at any time).

      • by DarkOx ( 621550 )

        Why?

        I keep reading similar comments over and over again but I really want the use case is! I agree it does not make any sense for browsers to treat self signed certs as riskier than plain HTTP, but why use HTTPs without authentication.

        Put another way, why worry who can see what your saying when you don't know who you are saying it to anyway?

        I totally understand a self signed cert for say connecting to a private network you control and have the certificates for. A company installing a their private CA cert

        • by locofungus ( 179280 ) on Wednesday April 06, 2011 @12:01PM (#35734906)

          Where you don't care about a determined attacker but want to stop a casual eavesdropper.

          For example a blog where you want to require users to login. Stolen passwords are a pain but not a major issue but being able to stop people just sniffing them off unencrypted wifi connections makes sense.

          Or want to stop ISPs seeing/hijacking pages to insert ads. Although ISPs could do a MITM attack on self signed certs, it's likely that before very long someone will notice an ISP doing it to one cert at which point people will very quickly see that it's happening to all of them.

          Many (most?) SMTP servers will negotiate TLS with self signed (or non "official" CA signed certs) if it's available. It would be interesting to know how many email servers are setup to refuse to send if the cert cannot be verified. I'm sure there are some servers out there that do this (and they're probably only allowing manually installed CAs as well) but I expect they're few and far between.

          Even between my home mail server that receives my mail and the backup mailserver I have if my home server is unavailable I forward using TLS (and the CA is installed) but I've not even considered bothering to block it if the certs don't match. If MI5 or the police decide they do want to intercept this mail then I probably wouldn't notice as the only visible symptom would be in the mailserver logs where it would no longer say the cert verified OK but someone at an ISP in the link is not going to accidentally start copying my mail traffic like google did with WIFI.

          Tim.

        • The reasoning is that the vast majority of the time, no one is doing a man-in-the-middle attack and furthermore that doing a man-in-the-middle attack on any significant proportion of the connections on the internet is assumed to be above the capabilities of any known attacker, so it means that you are probably talking to the owner of the DNS entry and normal passive sniffing attacks (ex. Firesheep) won't work. Also, the attacker may not be able to tell which connections are verified and which ones aren't (e

    • by yakatz ( 1176317 )

      All browsers shall be required to stop trusting those inexpensive standard SSL certs, as well as certs issued by budget CAs. 'Extended Validation' certs will now be baseline, with prices remaining unchanged, and two new levels of verification will be added:
      'Extended Validation: Pinky Swear!'
      'Double-Secret Extended Validation'
      This should solve all CA related trust issues.

      I read this an laughed, but then when I thought about it, you should not even suggest this kind of idea.
      Making it more expensive to be secure is not a step in the right direction.

    • and two new levels of verification will be added: .... 'Extended Validation: Pinky Swear!' ... 'Double-Secret Extended Validation'

      Well played sir.

    • by snsh ( 968808 )
      The major issue it would solve is trust in CA's by their shareholders that they will continue to earn profits.
    • Or how about we just give up with the idea of for profit third party authentication altogether and use either a handful of open authentication sites or just fall back on a distributed web of trust. I find the whole idea of founding our public key encryption systems on trusting a private, for-profit corporation to be laughable to begin with.

      And the Mozillia/Firefox Debacle over self-signed certs would be funny right now if it wasn't so offensive.

      • by dkf ( 304284 )

        just fall back on a distributed web of trust

        Won't scale up, as it fails to take into account the fact that the world is full of idiots and assholes. Assholes will try to poison the trust web ("for great profit!") and idiots will act in ways that let the assholes do it without any way to get back at them.

        The problem with the system of CAs is that nobody seems willing to pull the plug on crap ones. If CAs knew that they'd get kicked out of the magic money farm for screwing up, they'd take the right level of care. (Especially if they'd then have to fend

    • I don't see the problem. The existing process simply needs to require you to send something (by snailmail, email, or fax) on Company Letterhead.

      Since "using fake letterhead to spoof a request to a CA" has recently been patented as a business method, the patent would stop any bad guys from requesting fake certs, and all your certs are now secure, again.

  • by Richard_at_work ( 517087 ) on Wednesday April 06, 2011 @08:47AM (#35732342)
    Where are the EFFs SSL Observatory getting their data from, how well has it been validated? Their website only says "We have downloaded datasets of all of the publicly-visible SSL certificates on the IPv4 Internet" which doesn't say anything really - who is compiling this data and how are they doing it?
    • by fuzzyfuzzyfungus ( 1223518 ) on Wednesday April 06, 2011 @08:51AM (#35732390) Journal
      "For the technical research community, our source code as well as a MySQL database dump (August 2010 MySQL dump), the raw data (August 2010 raw data), and the August 2010 CSV database dump are available. You can also use the Observatory in an Amazon EC2 instance we created."

      From the main page [eff.org]...
      • Uhm, yeah, thats the EFFs dataset and I saw that while writing my original post (yeah, I rtfa'd - someone does do it!)...

        I'm talking about the origins of that data, where did it originally come from, how can they compile datasets of SSL certificates (which have no centralised point other than the CAs themselves - so are the CAs giving out information on cert signings?)
        • I assume that they crawled the web, looking for https:/// [https] addresses and then scraped the information from those, since a given host attempting an SSL session will present the details of its cert and who signed it.

          For their big-map-o'-CAs, it looks like the information you would need would be within available browsers, which by necessity come with a list of CAs that they trust, possibly with a bit of legwork to see if there are subordinate CAs involved...
          • That wouldn't give them certs signed for unqualified domains however, would it? They wouldn't be able to crawl the web for "localhost"...
            • by joostje ( 126457 )
              you crawl https on mail.nonlocalhost.com, and discover it claims to be domain "mail", and present a cert for domain "main".
              • you crawl https on mail.nonlocalhost.com, and discover it claims to be domain "mail", and present a cert for domain "main".

                That host doesn't listen on port 443 (https), and on port 993 (imaps), it uses a self-signed certificate for *.mail.dreamhost.com

                Still very goofy, but not quite as bad as a certificate for mail signed by a "legitimate" CA.

        • by higuita ( 129722 )

          they probably are doing something like the below script
          please ignore the invalid IPs, localhosts, private ips, multicast, etc, this is just a quick script... a perl version would probably be faster and more intelligent :)

          for a in {0..255} ; do
          for b in {0..255} ;do
          for c in {0..255} ; do
          for d in {0..255} ; do
          echo | openssl s_client -connect $a.$b.$c.$d :443 2>/dev/null | sed -n 's%0 s:.*/CN=\([^/]*\).*%\1%gp' > https.log

        • by afidel ( 530433 )
          I'm assuming they spidered the IPv4 address space looking for SSL connections and downloaded any certs they found.
  • I was just working on a PC with a virus that routes all traffic through some sort of SSL MITM mechanism.

  • Our mailserver has a REAL fqdn.... mail.XXXXX.com. Its only ever refered to by this.... so how would having mail as a cert help? :/

  • I'm sorry, but haven't most of us, in the back of our minds, known all along that the whole SSL thing is just a money scam?!

    Even if the commercial CA's get there act together, there are still plenty of CA's that my browsers trust by default but are in fact highly suspect. SSL can provide real security, but not through public CA's that are blindly included in your browser/OS.

  • It would be immediately obvious when someone performed a MitM attack using a valid certificate for "webmail". Why? Because the real certificate is signed by a ghetto CA that isn't trusted by any of the "major" vendors, and both the certificate and some of the intermediates have long since expired.

    I'll be worried if I can access that site without a bunch of ugly warnings popping up.

The best things in life go on sale sooner or later.

Working...