I have never particularly liked Virtual Private Networking (VPN). From the old days, when there were a gadzillion of proprietary implementations, each being super slow, resource hungry, and requiring a mess of versions specific requirements, like Java and Firefox. Secure Shell (SSH) has always been my choice for remote connections and tunneling.
Today I came across this article, which also shows that SSH tunnels are much faster than OpenVPN (if one has to use VPN, OpenVPN is probably the best choice around). Needless to say they are also much easier to setup, both manually and automatically.
This adds yet another argument to my SSH vs VPN toolbox.
GitHub blog recently announced a couple of interesting new features.
Secondly, Team Discussions. This is yet another way place for the team to communicate. There are Issues and Pull Requests already. But those are more specific and more focused. For anything that doesn’t have a single issue, or doesn’t have a PR yet, a Team Discussion might be a better place.
A while back I wrote this blog post on the subject of using SSH via bastion hosts. If you are into this sort of thing, have a look at this blog post by my brother. He is providing a few more explanations and clarifications, as well as covers a tricky to troubleshoot case with non-default location of your SSH configuration files and keys.
If you are a Linux old-timer, who is used to iptables (or even ipchains, or even … anyway), you might find “Firewalld configuration and usage” guide very handy. It covers firewalld concepts and provides a number of examples for zones, ports, services, interfaces and other bits and pieces that you might be scratching your head about, when configuring the modern Linux firewall.
This Front-End Checklist is pretty awesome and quite extensive:
The Front-End Checklist is an exhaustive list of all elements you need to have / to test before launching your site / page HTML to production.
It is based on Front-End developers’ years of experience, with the addition from some other open-source checklists.
The best part is that large parts of this list are pretty easy to automate and integrate with your deployment / continuous delivery tool chain.
Arnes Blanert wrote an extensive article for the architect magazine on the subject of Single Sign On (SSO). It covers both authentication and authorization via a variety of widely and not so widely used methods, including oAuth, SAML, JSON Web Token and more.
As someone who was involved in a variety of Single Sign On implementations (see some of the posts on the subject in my blog), I wish I had an article like this in my RSS feeds much much earlier.
“The Birth And Death Of Privacy: 3,000 Years of History Told Through 46 Images” is a rather extensive look at the history of privacy.
Privacy, as we understand it, is only about 150 years old. Humans do have an instinctual desire for privacy. However, for 3,000 years, cultures have nearly always prioritized convenience and wealth over privacy.
I said “there is no such thing as privacy, and there never was” way too many times. But I never had to go deep into the subject to defend it. This article, on the other hand, does a much better job defending the argument than I ever cared to.
BeEF is a browser exploitation framework.
BeEF is short for The Browser Exploitation Framework. It is a penetration testing tool that focuses on the web browser.
Amid growing concerns about web-borne attacks against clients, including mobile clients, BeEF allows the professional penetration tester to assess the actual security posture of a target environment by using client-side attack vectors. Unlike other security frameworks, BeEF looks past the hardened network perimeter and client system, and examines exploitability within the context of the one open door: the web browser. BeEF will hook one or more web browsers and use them as beachheads for launching directed command modules and further attacks against the system from within the browser context.
AWS Blog lets us know that Amazon has finally implemented one of the most useful features ever – descriptions on Security Groups rules. Previously, one could provide a description to the Security Group only, for example: “Proxy Server Access”. Which wasn’t very useful, as it was almost obvious. But now one can add a description to every rule inside the Security Group. So when you have a Security Group with a bunch of IP address ranges, you can now describe each one of them. For example: “HQ Office”, “UK Office”, “Boss At Home”, etc.
“The end of CSRF?” blog post talks about the new feature coming to browsers – SameSite cookie enforcement, which will help in getting rid of Cross-Site Request Forgery (CSRF) attacks. Too bad this is currently only supported by Google Chrome (both desktop and mobile), and Opera. But I’m sure it’s coming soon to the rest of the browsers.
Update: It looks like the above blog post is almost a copy of this blog post, which has a number of useful comments. Including this one, which links to a variety of projects and programming languages bug trackers requesting the support of the SameSite cookie feature. Also, it looks like SameSite cookie is superseded by the Cookie Prefix solution, proposed by Google.