summaryrefslogtreecommitdiff
path: root/blog/2014
diff options
context:
space:
mode:
authorerdgeist <erdgeist@bauklotz.local>2015-08-16 16:38:25 +0200
committererdgeist <erdgeist@bauklotz.local>2015-08-16 16:38:25 +0200
commit23f0e1561767dd8a396188e317bae5920d171ea8 (patch)
treea67f44e39ad8a45e42d60634488a65c37f3ad432 /blog/2014
Initial import of my nikola website
Diffstat (limited to 'blog/2014')
-rw-r--r--blog/2014/Self-righteous_spam_police.md61
-rw-r--r--blog/2014/Using_libressl.md30
2 files changed, 91 insertions, 0 deletions
diff --git a/blog/2014/Self-righteous_spam_police.md b/blog/2014/Self-righteous_spam_police.md
new file mode 100644
index 0000000..6efb17b
--- /dev/null
+++ b/blog/2014/Self-righteous_spam_police.md
@@ -0,0 +1,61 @@
1<!--
2.. date: 2014/01/22 10:04
3.. title: Self-righteous spam police
4-->
5
6For 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.
7
8Imagine our surprise when we suddenly were served bounces like
9
10> Remote host said: 554 5.7.1 Service unavailable; Client host [217.115.13.199] blocked using bl.spamcop.net;
11> Blocked - see http://www.spamcop.net/bl.shtml?217.115.13.199
12
13basically denouncing us as spammers. When investigating the issue, we were informed that
14
15> Causes of listing:
16> System has sent mail to SpamCop spam traps in the past week (spam traps are secret, no reports or evidence
17> are provided by SpamCop).
18
19our 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=217.115.13.199> told us,
20
21> Dispute Listing:
22> If you are the administrator of this system and you are sure this listing is erroneous, you may request that we
23> review the listing. Because everyone wants to dispute their listing, regardless of merit, we reserve the right
24> to ignore meritless disputes.
25
26basically 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.
27
28At 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.
29
30I dug a little deeper and found that the spamcop project actually makes money selling it’s block list to other mailers in need of immediate updateso 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?
31
32After 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
33
34> This IP is listed because it is sending spam to our traps. Traps are addresses on our systems that have never
35> existed and could never subscribe to be on any mailing list. Any mail to them is spam. We will not provide any
36> information that identifies our traps or their locations.
37
38but also providing a sample of the spam they received. And indeed
39
40```text
41 Received: from elektropost.org ([217.115.13.199]) helo=elektropost.org
42 by <removed>; Tue, 21 Jan 2014 17:xx:xx -0800
43 Date: Wed, 22 Jan 2014 08:xx:xx +0700
44 Message-ID: <2172___________________3767@gasz.nl>
45 From: Online Casino <hqbwrgayueue@gasz.nl>
46 To: <x>
47 Subject: Ihr Ziel: Profit
48```
49
50this 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.
51
52Now, 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>:
53
54> Traps must consist of email addresses which have never been used for legitimate email. They should not
55> be "recycled" user accounts.
56
57However, they never seem to verify, if their contributors actually follow those guidelines. In our case, a simple google search would have warned them.
58
59I 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.
60
61In 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.
diff --git a/blog/2014/Using_libressl.md b/blog/2014/Using_libressl.md
new file mode 100644
index 0000000..d0bb138
--- /dev/null
+++ b/blog/2014/Using_libressl.md
@@ -0,0 +1,30 @@
1<!--
2.. date: 2014/05/19 04:20
3.. title: Using libressl
4-->
5
6I’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 whether they can trust the new library and should make their code depend on libressl.
7
8I have prepared a simple FAQ for them:
9
10* Q: Should I base new code on the libressl API?
11* A: No.
12
13The reason is as simple as it gets. libressl was designed as a drop-in-replacement for openssl to protect the only asset openssl still has: an API that (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.
14
15Thing 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.
16
17Now, 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.
18
19Most 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 into one (and even adds dangerous cruft like kerberos):
20
21a secure and sanely configured certificate exchange-, parser- and checker- library,
22a library of sane (and BY DEFAULT SECURE) crypto primitives that can apply ciphers on a data stream,
23a set of standard conforming heuristics that will (re-)negotiate cipher suites based on 1) and the availability of ciphers from 2)
24openssl 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.
25
26Now 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.
27
28If 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 [the available TLS implementations](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 it gives you and where you need it.
29
30Until then rest assured that securing your application is not just a case of linking in another unreviewed lib.