- monthly subscription or
- one time payment
- cancelable any time
"Tell the chef, the beer is on me."
Iâve been committing some code to the ressl project. Iâve found it worth to spend some time on that project that aims to make securing your communication more secure. But still people have some misconceptions about wether they can trust the new library and should make their code depend on libressl.
I have prepared a simple FAQ for them:
The reason is as simple as it get. libressl was designed as a drop-in-replacement for openssl to protect the only asset openssl still has: an API that is (even though itâs broken as hell) still is used widely. While theyâre doing this, they try to do everything right that can be done right in a 201*-ish project.
Thing is, openssl is not actually there to provide you with secure software, but to implement the ânobody ever has been fired for using opensslâ-aspect of your average âcryptoâ-library. Itâs â well itâs there and it has some FIPS certification. But letâs face it: the code is terrible, the âmaintainersâ havenât done any maintenance besides reselling their FIPS-asset, the API is terrible, the cipher-defaults are terrible, the interfaces into certificate checking are next to unusable, the core functionally works hard to cloak their badness from any modern bug detection heuristics, covering most of their bugs, and opensslâs maintainers ignore bug reports, because fixing them would break their certification, hurting their business of selling FIPS-consultancy.
Now, the OpenBSD guys were facing a tough challenge: write just another SSL library with a sane API that no one is going to use, or clean up the library that is de-facto standard and hard to rip out of each and every tool that tries to connect to the interwebs securely.
Most users of the openssl library come there, because they stumbled across transport security as an afterthought. Maybe because itâs been another tick on their compliance chart, or because theyâve seen the passwords flowing through their wireshark window â throw some crypto on it, they thought. What they need to realize is, that they actually need three separate libraries in the first place â which openssl conveniently layer-violates them into one (and even add dangerous cruft like kerberos):
openssl fails in every single aspect of this. 99,999 percent of users nowadays do use openssl to secure their socket-based communication on servers or clients talking with each other via TCP. The whole BIO abstraction provided by openssl is wasted on them. The stack-like approach to look at âchainsâ of certificates falls short on modern setups with several expired and unexpired certs of the same CA in a single key store. You still can â as a MITM âÂ trick most openssl setups into using null ciphers or weak algorithms. Checking CRLs still is a black art done right by no one. openssl still implements each and every memory allocation level bug ever displayed on âsoftware security 101â in your favorite university.
Now I will â judging by the current progress â give ressl a year until they matured enough to acknowledge them having picked all low hanging fruit. Then OpenBSD can proudly (and rightfully) announce that software linked agains libressl on their (and other) platforms is much more secure than before. And after looking into the source code I also understand that fixing it while also inventing a saner API exceeds the OpenBSD teamâs capacities. So I urge you to consider what exactly you need secured and what tools provide you exactly what.
If youâre up to implementing secure communication between your app and your server or between your appliances, first check if you really need all the TLS features â like the whole set of X.509 features that openssl gives you (and if so, check back which license of http://en.wikipedia.org/wiki/Comparison_of_TLS_implementations could possible also suite your needs) â or if you can just go with a public domain library like NaCl http://en.wikipedia.org/wiki/NaCl_(software) and put a little thought into what cryptographic primitives give you and where you need it.
Until then rest assured that securing your application is not just a case of linking in another unreviewed lib.
For over 15 years Iâ€™ve been â€“ together with friends â€“ running elektropost.org, a community mail server that provides free email accounts and mailing lists for friends, family, several NGOs and small companies â€“ so they donâ€™t have to turn to google mail or worse. We pride ourself in being good netizens, providing spam filtering, discarding our double bounces and so on.
Imagine our surprise when we suddenly were served bounces like
Remote host said: 554 5.7.1 Service unavailable; Client host [188.8.131.52] blocked using bl.spamcop.net;Blocked - see http://www.spamcop.net/bl.shtml?184.108.40.206
basically denouncing us as spammers. When investigating the issue, we were informed that
Causes of listing:System has sent mail to SpamCop spam traps in the past week (spam traps are secret, no reports or evidenceare provided by SpamCop).
our system has sent an email to a secret mail address guaranteed to only receive spam emails. Any protest is futile, the website http://www.spamcop.net/w3m?action=blcheck&ip=220.127.116.11 told us,
Dispute Listing:If you are the administrator of this system and you are sure this listing is erroneous, you may request that wereview the listing. Because everyone wants to dispute their listing, regardless of merit, we reserve the rightto ignore meritless disputes.
basically saying: All the bad guys say that they are not the bad guys, so â€¦ sure, go on, drop us an note, whining about how bad the world is and we ignore it. Because you are a spammer. And we know because we said so.
At this point I would have just ignored them, after all the internet told me that they even put gmail on their RBL. But it turned out that several larger sites actually use the lists provided by spamcop and the amount of bounces started to hurt our community mail server.
I dug a little deeper and found that the spamcop project actually makes money selling its block list to other mailers in need of immediate updates for US$1000: http://www.spamcop.net/fom-serve/cache/340.html and, worse they even sell email accounts for US$30 per year http://www.spamcop.net/ces/pricing.shtml which clearly indicates a conflict of interests. â€œUnfortunate mis-listingâ€� of other free mail servers now appears as defamation of potential competition. So they better have their facts straight! But â€“ have they? How to find that out, if they never want to present their proof of me being a spammer?
After failing to provide my email address as abuse-contact for our mail server at abuse.net â€“ due to our mail server being on the black list (oh, the irony), I focussed on writing the most brown-nosing post on their feedback system. I explained, that we kept our system tidy for over a decade and would appreciate some assistance in resolving their claim. After a while I received an email, again explaining, that
This IP is listed because it is sending spam to our traps. Traps are addresses on our systems that have neverexisted and could never subscribe to be on any mailing list. Any mail to them is spam. We will not provide anyinformation that identifies our traps or their locations.
but also providing a sample of the spam they received. And indeed
Received: from elektropost.org ([18.104.22.168]) helo=elektropost.org by <removed>; Tue, 21 Jan 2014 17:xx:xx -0800Date: Wed, 22 Jan 2014 08:xx:xx +0700Message-ID: <firstname.lastname@example.org>From: Online Casino <email@example.com>To: <x>Subject: Ihr Ziel: Profit
this very much looks like spam, originating from our mail server. I also found some traces of that email in my rather sparse mail server logs and was flabbergasted for a moment, how this could have been relayed through the server without anyone authenticating. Fortunately I found a corresponding incoming spam mail to one of our users accounts, I found a mail forward set for this user to the address that obviously now serves as one of spamcops spam traps and from then on it all became clear. That user has set up a dedicated vacation account and forwarded all emails from that account to a satellite mail provider. The user also wrote several blog posts, pointing potential co-travelers to this address. The provider shut down the account a while ago and now decided that since nearly every email to this account looks spam-ish, it would make a perfect spam trap.
Now, even our overeager friends at spamcop have noticed that re-using a once legitimate address is a stupid idea, from http://www.spamcop.net/fom-serve/cache/402.html:
Traps must consist of email addresses which have never been used for legitimate email. They should notbe "recycled" user accounts.
However, they never seem to verify, if their contributors actually follow those guidelines. In our case, a simple google search would have warned them.
I just wrapped up all this in an email to the hard-working â€œdeputiesâ€� they employ over there at spamcop HQ and hope for a quick de-listing, and maybe â€“ just maybe â€“ for an apology.
In the end all left to conclude is: Do no put the burden of fighting spam on others. My users actually experienced bounced emails, I experienced two days of debugging and fixing other peoples amateurish setup, our projectâ€™s reputation was damaged. Spamcop, your secret spam traps are a stupid idea and they hurt the community, in our case possibly driving users away from a privacy-aware project to other freemailer providers that are large enough to have resources to deal with problems like you.
"Tell the chef, the beer is on me."
"Basically the price of a night on the town!"
"I'd love to help kickstart continued development! And 0 EUR/month really does make fiscal sense too... maybe I'll even get a shirt?" (there will be limited edition shirts for two and other goodies for each supporter as soon as we sold the 200)