A night without sleep later I am slowly getting a clearer picture of how the pieces are fitting together. Ricing my blog is getting smoother and smoother as my understanding of sblg, HTML and CSS increases and I was able to unclutter both my Makefile and the HTML code. But there is a lot of additional chopping to be done.

I also managed to upgrade my bootstrap version and all of the open points mentioned in my first post are more or less resolved. The only missing thing is a way to make tags clickable so you only get to see articles matching a specific tag but as I don’t expect too many people to show up here in the near future this is not very high on my priority list.

So far I really enjoy sblg as it makes me getting to know HTML and CSS and learning something new or getting to know something better is always very enjoyable to me. I even improved the experience of my website on smaller devices, with only one thing missing: that damn sidebar won’t go away 😕.

So hopefully no more distractions as I am actually in the process of cooking up a new post which might be the introduction to a new series of posts focussing on the topic of getting a deeper undestanding of one’s network.

I knew that an aquaintance of mine, Oliver Paukstadt, had been in contact w/ Apple about something related to IDN. Up until recently I was unaware of the exact details but I feared that due to his actions the last vendor I know off would stop rendering my emoji domain as unicode but would also go ahead and display punycode instead.

Luckily I dodged that bullet ;-)

But I wondered what’s it all about CVE-2017-7106. The gist seems to be about unicode confusables as he is keen to demonstrate over at Thinking Objects’ blog. While I can see where he is coming from (just visit to.com and his demo tᴏ.com from an iOS10 device) but I still am not convinced that this is solving any real issue. Just to be clear, this is not meant to belittle any of his work.

Just stick with me and have a look at the following two address bars in iOS11:

The first image shows a supposedly correct punycode notation, the second displays something that is looking like punycode but then again it’s not. The first dash is actually the unicode glyph for the En dash. Even worse, if you quickly type two normal dashes on iOS11 they are automatically replaced by the En dash. So I wonder how many people would not only miss that one but actively fall into this trap. And if I would be out spear phishing one victim is all it takes.

Yes, this wouldn’t be a viable phishing campaign as other browsers like e.g. firefox are transliterating xn–t-26l.com into xn--xn-t-26l-tn3d.com but don’t feel too safe already.

Let’s say iOS11 would also transliterate the above example into punycode thus obviously showing that something is very phishy. But imagine all the non English folks that would like to use their language naturally without the need to convert anything to 7-bit ASCII. They’d be trained to see punycode everywhere and so we open the door for an old attack: typosquatting.

I don’t think a lot of people would spot the difference between xn--t-26l.com and …

Update: I have corrected chown www /var/www/data to be chown www /var/www/rainloop/data in getting rainloop ready to rock

• installing php and php-curl (and unzip)

    pkg_add -i php php-curl unzip
  

• getting rainloop ready to rock

    mkdir /var/www/rainloop
    unzip ~/rainloop-community-latest.zip -d /var/www/rainloop
    cd /var/www/rainloop
    find . -type d -exec chmod 755 {} \;
    find . -type f -exec chmod 644 {} \;
    chown www /var/www/rainloop/data
  

• configure php

    ln -s /etc/php-7.0.sample/curl.ini /etc/php-7.0/
  

• enable php-fpm

    rcctl enable php70_fpm
    rcctl start php70_fpm
  

• setup httpd

    location "/rainloop/data/*" {
            block
    }
  
    location "/rainloop/*.php*" {
            root { "/rainloop/", strip 1 }
            fastcgi socket "/run/php-fpm.sock"
    }
  
    location "/rainloop/*" {
            root { "/rainloop/", strip 1 }
            directory index "index.php"
    }
  

• reload httpd and go to https://your.tld/rainloop

    rcctl restart httpd
  

Just in case somebody else is getting the cannot resolve getgrav.com error: just copy /etc/resolv.conf into the chroot:

	mkdir /var/www/etc
	cp /etc/resolv.conf /var/www/etc/

And I already feared that I need to create /dev/random and shit like that. Damn it that took too long to find out.