]> Sergey Matveev's repositories - stargrave-blog.git/log
stargrave-blog.git
17 months agoMy opinion on OpenPGP critique english
Sergey Matveev [Fri, 11 Nov 2022 10:32:14 +0000 (13:32 +0300)]
My opinion on OpenPGP critique

>https://latacora.singles/2019/07/16/the-pgp-problem.html

There are plenty of other articles like this, including the well-known
Matthew Green cryptographer:
https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/
https://words.filippo.io/giving-up-on-long-term-pgp/
https://secushare.org/PGP and some answers on that:
https://pthree.org/2014/08/18/whats-the-matter-with-pgp/
https://articles.59.ca/doku.php?id=pgpfan:tpp
And there are also many others.

Some of them are just lame, because author treats OpenPGP only as a way
to secure real-time (instant messaging, chats) communications. And they
suggest something like Signal. They compare apples to oranges. Some of
them, including latacora's one, just outdated from technical perspective.

OpenPGP allows file encryption and file signing. That is basically all.
And it allows sending encrypted/signed data to the remote side
immediately: you gather (somehow) recipient's public key and, without any
direct interaction with him beforehand, just sends him a message/file.
All suggestions like Signal/OMEMO/whatever requires you to be online
during conversation, to use interactive (from technical point of view)
many round-trip protocol.

That is why OpenPGP does not have forward secrecy property (no ephemeral
keys are involved). That is why neither Signal, nor OMEMO can replace
OpenPGP if you have no ability to stay online. Email is not interactive
and online communication system. IMs are. Suggestion to replace email
with IMs is just ridiculous. Those systems are for different tasks. It
is like suggesting to stay at home to watch the movie, as an answer to
the question "what automobile I should buy: electrical or gas one?".

"signify" utility is indeed the great one. But it does not encrypt
files. "age" utility to also good, but it does not sign/authenticate
messages. Can you just signify age-encrypted files? Or maybe age-encrypt
your signified file?
https://words.filippo.io/dispatches/age-authentication/ tells us:

    If you encrypt and then sign, an attacker can strip your signature,
    replace it with their own, and make it look like they encrypted the
    file even if they don't actually know the contents.

    If you sign and then encrypt, the recipient can decrypt the file,
    keep your signature, and encrypt it to a different recipient, making
    it look like you intended to send the file to them.

So those two utilities just can not replace so easily and transparently
OpenPGP in that relatively simple task like "signcryption" (as filippo.io
calls it).

Maybe you do not need signcryption, just authentication/signing? Ok,
signify is enough. Or actually now, in my opinion, it is better to use
ssh-keygen from modern OpenPGP, that has built-in ability to sign/verify
files using already existing OpenSSH keys. Maybe you need only encryption?
Ok, age is enough for you. Maybe you are pretty ok with online real-time
interactive communications for chatting? OpenPGP is definitely not the
best tool there, because it is not forward secret. What if you really
need that forward secrecy option? Then OpenPGP for chatting is
definitely not satisfactory. ***Various*** tasks require various
software. None of the software above is capable to fully replace anyone
in every task.

Next subject: trust management. Many articles tell us about complexity
of OpenPGP key management. It is true. But only because trust and key
management is *really* a complicated tasks. Most people can be satisfied
with the third party for authentication, like X.509 PKI system works and
"secures" our HTTPS connections. *Most* people are completely ok with
"apt install letsencrypt" and automatically gaining X.509 certificate
for their domain for free from Let's Encrypt company. But not *all* can
be satisfied with that, because Let's Encrypt is just a single
centralized USA-controlled point of authentication, that is just awful
for many tasks. And for me it is completely unacceptable to allow USA
full control over the authentication of my services. PKI is only the
business model, it gives no *serious* security against more or less
powerful adversaries, like USA government/forces for example. It secures
about your neighbour connected to the same router/switch with you.
http://www.stargrave.org/WhyNotLE.html

Most people can treat the system as secure, if it is allowed to be
MitMed by governments. Some people can not call it secure at all. So
there are various attack threats, various definitions for acceptable
security. Signal requires me to bind cellphone number to the account:
that is *completely* unacceptable to me, but can be acceptable to many
others. But I won't say that Signal is not secure. And nobody should
call Signal's model as secure -- it is just different, it has different
pros and cons, has different compromises. Acceptable to one people, not
acceptable to others.

So trust management in OpenPGP is complicated, because it tries to
fitful everyone. You want completely manual trust setting for each key?
Use manual model of trust. Someone is ok with WoT (Web-of-trust, when
people sign other people's keys). Someone is completely not ok with WoT,
because it leaks relations between the participants, it has privacy
issues. Someone is ok with TOFU (trust on first use). There are so many
options because there are so many various requirements in people.
signify/age utilities does not have any kind of trust management except
for manual setting of allowed keys. It is ok for 90%+ of users. As Let's
Encrypt is ok for 90%+ of users. But OpenPGP technically can cover 100%
of all users in that trust management field. Nothing prevents you to
create the same X.509 PKI model in OpenPGP: just use WoT with some
trusted third-party and tell that you fully trusts its decisions.
OpenPGP just does not force you and bias to any kind of trust model,
that is why it is more complicated and any complication unfortunately
leads to user interface/experience complexity and burden. It is just
more advanced and serious tool for wide field of tasks and trust models.

Next subject: long term keys are bad. And the immediate question arises:
for what task? If I am maintaining software and sign its packages, then
hardly you could live without any kind of long-term identity. I know, I
know -- many people have never ever verified any downloaded software,
that is why so that many people deal with viruses, trojans, keyloggers
and other malicious software. For me, life with untrusted malicious
software on my computer is not acceptable, like it is for most people.
That is why trust management and trust communication is something very
necessary. Also most people are ok just to trust single entity, like
Apple's software repository (AppStore), and they are ok with all that
censorship they do in it and even their terms of use incompatible with
free software definition:
https://www.fsf.org/news/2010-05-app-store-compliance
https://www.fsf.org/blogs/licensing/more-about-the-app-store-gpl-enforcement

Is OpenPGP appropriate for IM and chatting? It can secure your channel,
like now it secures our email conversation, but of course with neither
deniability, nor with any forward secrecy. But why people suggesting to
use Signal/whatever centralized solutions to that? Nearly twenty years
ago appeared Off-The-Record (OTR) protocol, that is included in most
IRC/XMPP/generic-chat clients I have seen out of box. I can use irssi
IRC client with any existing IRC server and just use OTR messaging on
top of it -- and deniable, forward secret channel is established. Ok,
OTRv3 is kind a ancient nowadays: it uses huge and slow RSA keys, and
shares them with each message, that can be noticeable on slow machines.
But does it means that it is unappropriate for secure chatting? It is
not ideal, but its support is widespread and is independent from the
transport channel you use (use it on top of virtually anything that can
exchange text messages). Why should I move to completely different
software, servers, protocols and ecosystem, if OTR gives more than
enough proven security? If you already use XMPP ecosystem and have got
OMEMO-capable clients, then of course OMEMO is more preferable than
OTR, just because of more efficiency (because of ECC keys). But using
OTR is also nothing wrong. And using OpenPGP does not mean that you will
definitely leak your keys and all your conversation will be disclosed
and everything will be ruined. There are some risks, that can be
accepted or not. Someone accepts X.509 PKI model, someone not. Someone
accepts lack of forward secrecy, if there is no ability (or wish) to use
online interactive real-time channels.

By the way, I am aware that neither Signal, nor OMEMO does not require
presence of the chat participants all the time, unlike OTR. They
beforehand generate hundred of ephemeral keys and store them on the
server. If somebody wants to chat with them, but they are offline, the
server gives them one of those preloaded ephemeral keys. Good solution
for most of users. But what if more than hundred of chats started? What
if server is down or lost those keys? All of that are just tradeoffs.
Completely clean solution without *any* server's knowledge of the
protocol, like in OTR -- can be good, can be bad in some situations.
Server's participation in Signal/OMEMO/whatever protocol and its bigger
complexity -- can be bad, can be good tradeoff. There is no single
evaluation of that.

Next subject: cryptography algorithms and security. Many articles
(including latacora's) tells about MDC and https://efail.de/. All of
that is an olde bullshit already. For long time none of GnuPG versions
do not accept MDC-less messages. EFAIL is a failure of MUAs, not OpenPGP
itself. EFAIL is about how MUA developers made stupid insecure
expectations from underlying cryptography library and failed there. Many
people talk about huge RSA keys. For years GnuPG already ***by default***
uses ECC ed25519/cv25519 ones. Those short fast and secure algorithms
are used already by default. Some people talk about MDC even more. But
again, modern GnuPG versions supported AEAD encryption modes for years
already. Personally I use OCB-mode and it is the fastest encryption
speed I see on my hardware (with hardware accelerated AES). My current
GnuPG is literally capable of precessing more than 1.2GiB/sec of data on
a single core with VERY safe OCB mode, unlike the GCM one. Currently
GnuPG is just state-of-the-art on algorithms selection.

And some words about latacora's article more. Author writes about janky
GnuPG's code. That is just ridiculous. Any software has CVEs. But can
someone remember any catastrophic and fatal security issues with GnuPG
and its libraries? I remember only one: when ***Debian*** maintainers
patched it and completely broke its PRNG, so thousands of generated
OpenPGP keys were completely insecure. But that was Debian's fail, not
GnuPGs. And compare it with OpenSSL, that has many of fatal,
catastrophic completely ruining bugs and problems like BEAST and
Heartbleed: https://en.wikipedia.org/wiki/OpenSSL#Notable_vulnerabilities
GnuPG (and its corresponding libraries code) is one of the best code by
quality I have seen. When you (latacora) tell that some software is
junky/bad, then it should means that most other software is better.
GnuPG's software ecosystem is not perfect, but it is one of the highest
quality one we had.

And moreover, latacora advises to use ***online*** backup service. WAT?

OpenPGP and GnuPG are not perfect, far from ideal, complex indeed
(because solves many tasks and do not force to use single trust model
for example) and have high entry barrier. All of that is right. Also
they do not provide forward secrecy (although you can generate a new
OpenPGP with each message and send it together -- and you achieve
forward secrecy, nothing prevents you doing that in practice!). But
personally I am pretty ok with lack of it, because that is acceptable
risk for me (I really do not believe that my key will be leaked -- most
likely I will fall somewhere, will hit my head and forget my passphrase).
But at the same time, GnuPG has very high quality code, dozens of years
of experience and proven technology software, and by default it is
installed just our of box on most GNU/Linux distributions (do not know
about nowadays, probably I am wrong, because each year GNU/Linux sucks
more and more, transforming to yet another Windows/macOS). You *know*
that you can send OpenPGP signed/encrypted data to someone on the other
end and he will be able to process it. "signify" is installed neither on
GNU/Linux nor on all BSD systems. "age" is not installed everywhere too.
And moreover it is also far from being ideal: my gohpenc utility
http://www.git.cypherpunks.ru/?p=gohpenc.git;a=summary can parallelize
and is many times faster than age. They are not interchangeable, but age
is far from being the fast one (GnuPG with OCB encryption mode
completely outperforms it). Someone requires high performance.

18 months agoMy opinion on privacyguides.org
Sergey Matveev [Tue, 1 Nov 2022 13:06:37 +0000 (16:06 +0300)]
My opinion on privacyguides.org

>I discovered new website called privacyguides.org and they seem support
>privacy and security for censorship and cyberbullies. According to the
>their website the best secure OSes are Fedora, Arch Linux and Qubes
>(Whonix). Could you please check their claims?

Initially when I saw their website, then I liked it, because at least it
is just an up-to-date aggregator of various modern privacy-preserving
software. However then looked at it narrowly, I discovered some very
harmful and dangerous recommendations. Of course in my humble opinion.
All people have varying criteria.

I wanted to criticise several of their points, but let's walk over all
of their recommendations.

* Introduction to passwords: https://www.privacyguides.org/basics/passwords-overview/
  Use unique passwords for every service, rotate only when you think of
  compromise -- good advices indeed. Use either randomly generated and
  securely stored password with password manager, or use diceware
  passphrases -- also very good advices, perfect ones.

* Multi-Factor Authentication: https://www.privacyguides.org/basics/multi-factor-authentication/
  In general there are no mistakes in that part of recommendations, but
  it totally lacks more simple and easier to remember fact, that
  authentication can be performed either by something you "know", or by
  something you "have", or by something you "are". Passwords is
  something you "know". Asymmetric cryptography keys are something you
  "have". Biometric information is something you "are". SMS, push
  notification, OTPs are something you also have. That page is silent
  about the fact, that private asymmetric cryptography key encrypted by
  your passphrase is already a two-factor authentication. So ordinary
  OpenSSH with encrypted private keys can be treated like 2-factor
  authentication from cryptography point of view. Unfortunately remote
  side can not prove are you using your keys securely, and most people
  won't use any strong passphrases with them (if any at all), so they
  tend to force people using often weaker (from cryptography point of
  view), but somehow forced hardware security tokens or SMS/push
  notifications. It is better for most people, who just do not
  understand importance of the strong authentication, but that does not
  mean that it will increase security of (for example) OpenSSH model
  with passphrase and encrypted private key, assuming that your hardware
  is not compromised of course.

* Email security: https://www.privacyguides.org/basics/email-security/
  They are right about insecure nature by default and inability to
  secure the metadata (message headers). They mention OpenPGP and
  S/MIME. And the fact, that there is no forward secrecy for those
  security measures (you have to use online protocols for forward
  secrecy and possible deniability). Everything is right here.

* VPN: https://www.privacyguides.org/basics/vpn-overview/
  They are right that VPN is *just* a shifting of point of trust from
  your ISP to someone else. I disagree with their strong "Yes" answer on
  "should I use VPN?" question. Everything depends on where you move you
  point of trust, who *will* monitor your traffic now. For example if I
  will use some widely spread service like NordVPN (I just searched for
  VPN and saw its name in first results), then my private data will be
  collected by that huge (12M+ of users, as they claim) provider,
  instead of my local one in my small town with several thousands of
  users. My private data for local ISP is probably so invaluable, that
  it won't even collect it for possible further usage. My NordVPN/whatever
  big ones will definitely collect it, because... why not, 12M+ of users
  is valuable source of data. But yes -- it will hide your IP address
  from the end-entity website/service you are using. Or maybe it can be
  used to bypass some censorship/firewall restrictions. It is
  questionable is it useful and favorable from ethical point of view.

* Android: https://www.privacyguides.org/os/android-overview/
  They are right that stock Android is full of closed non-free software
  with definitely possible backdoors and huge number of privacy related
  misfeatures. But they are silent about the fact, that majority of
  those devices have communication chip connected to the same bus/memory
  as Android OS itself. And you have no control over that chip, that is
  always on and connected to the cellular network and can execute remote
  commands transparently from Android OS itself. Nothing prevents it
  from reading your memory with ephemeral private keys used for E2EE.
  Moreover, I highly doubt that "problem could be solved by using a
  custom Android distribution". That year I tried (just out of
  curiosity) to build LineageOS, that claims to be fully "open source"
  and so on -- there are HUGE number of binary prebuilt packages
  involved in the build process. I do not want to say that it is not
  possible to build everything from the source code, but LineageOS
  definitely does not provide that automation at all. Maybe Replicant is
  more serious about that? I did not check, but the whole Android
  ecosystem is some kind of strongly biased towards active use of
  prebuilt binaries of many components and build tools. In general, I
  can not even imagine bearable security regarding any kind of modern
  smartphones. The whole ecosystem is built upon control over the user
  and his abilities.

* I am glad that there is no information about iOS, where user is
  definitely under sole control of Apple, so forget about privacy.

* "Linux" (actually Android is also "Linux", but they also mention
  GNU/Linux operating system to clarify that term):
  https://www.privacyguides.org/os/linux-overview/
  They are right that "open source" will not magically make your
  software more secure, invulnerable to attacks, or privacy respecting.
  But free software is necessity for the possibility to create that kind
  of software. "FOSS" != "secure", but FOSS is *ability* to create it.

  They note that GNU/Linux system currently do not have so strong
  measures for "verified boot chain" and strong sandboxing. Maybe that
  is true, when compared to widespread non-free system. But "verified"
  boot chain is actually used for DRM (digital restrictions management)
  on them, for preventing user's abilities to make modification to his
  own device (yeah, yeah, because company thinks about user's security,
  as we heard many times before). And sandboxing is required on those
  systems because they are aimed to run non-free closed software, mainly
  with malicious misfeatures harming the privacy.

  Do I need strong sandboxing on my completely free software system? If
  it is fully free, then I expect it not to have something I wanted to
  avoid. At least I have got a possibility to do that in many cases. If
  I run trusted software, then it won't try to harm my computer, won't
  try to spy on me, won't do anything I will regret. So no need in
  sandboxing in that ideal world. But software contain bugs and can be
  attacked. So we need at least some exploit mitigations, that is true.
  That is why I can not treat "verified boot chain" and "sandboxing" as
  something highly required and necessary. They are made mainly to
  control user's abilities and aimed to run malicious proprietary
  software, that sane security/privacy-aware user do not want to run at all.

  They are right about "security-focused" distributions, that they are
  aimed for offence/attack, not defence.

  I strongly disagree with almost every other point they wrote:

  * They recommend "bleeding edge" distributions, saying that they will
    quickly apply security fixes to the packages. Strongly disagree with
    that, because every update in one of hundred/thousand packages you
    have is a risk of bringing yet another bug to it. Every update is a
    risk that something will misbehave or will stop working, because of
    slightly changed library's workflow. Every day you upgrade your
    bleeding edge system, you *will* expect something will be broken,
    something will be changed (maybe in backwards incompatible way).
    Some people will like that, some will want that. But the fact that
    you have constantly changing software, constantly having software
    that was not definitely by proven by time -- no way it can gain your
    security or privacy.

    Moreover, let's be honest: how many times any of your packages,
    libraries and software are affected by some *security* issue? I run
    my desktop system without any major upgrade for more than five
    years, following security announcements. And probably once or twice
    per year I really need to upgrade/patch anything. And non-bleeding
    edge distributions, like Debian, will anyway release
    serious/critical updates to their stable long-term versions. 99.99%
    of all software updates are about anything, but security issues. And
    only part of those issues will affect you and your system. For
    example if there is some vulnerability in kernel's PPP-module
    solely, then how it will affect people who used it last time more
    than twenty years ago?

    "Bleeding edge vs stable" versions is mainly a question of
    priorities and preferences. But stability is crucial for security.
    Real vulnerabilities are relatively seldom thing and they are fixed
    even in long-term stable distributions.

  * They strongly recommend against Linux-libre kernel, because they
    tend to treat constantly updating CPUs microcode as a security
    measure. Well, what can I say? I strongly recommend against using of
    kernel, that contains non-free software blobs, that downloads and
    changes your hardware ('s microcode), because noone knows what that
    yet another microcode update brings to you. Possibly yet another
    additional backdoor? Non-free software is completely unacceptable
    thing for anything related to security or privacy. Additional
    non-free software/blob/microcode/whatever -- decreased security.
    Automatically updated non-free software -- automatically decreased
    security and your computer is just remotely controlled. Their
    website literally recommends you to use *more* non-free closed
    software. Unacceptable thing and their site can be just silently
    closed and be forgotten.

    Moreover, are those CPU security vulnerabilities are applicable to
    the user who runs trusted free software? Nope, in general. So why
    bothering? But if users runs non-free software, understanding all
    negative consequences and his system breakage, then why he continues
    worrying about his privacy? If you have to run something untrusted,
    then use isolated separate computer for that task. At least only it
    will be affected by broken security countermeasures. Of course it is
    more expensive solution, but it is the only acceptable one I see.

  * They recommend Wayland, because X11 protocol allows screen recording
    and so on. Again -- why bothering, if you run trusted and controlled
    by *you* software? And if you run untrusted non-free software, then
    why bother about privacy at all? Why would you run non-free software?
    I am not against Wayland, but it is stupid advice concerning security.
    Question is simple: who controls your PC? If it is not you (you run
    non-free software), then exactly that is the main problem you have
    to solve, not the X11/Wayland-protocol security.

* Why there is no mention of BSD operating systems? I am convinced and
  sure that they are undoubtedly more secure and privacy respecting out
  of box. Each year I consider how less control you have other modern
  popular GNU/Linux distributions. Many (and page about "Linux" also
  notes that) distributions tend to automatically generate some unique
  identifier and use it during enabled-by-default software updates, that
  is completely incompatible with the privacy. Moreover widespread BSD
  systems are much more lightweight, minimalistic and easier to deal
  with, because there are just fewer number of unnecessary complex
  components involved. BSD systems as a rule are complete operating
  systems, done by the same developers throughout the whole components.
  That is why their quality and user experience tend to be much higher.
  Most security features appeared in GNU/Linux ecosystem were invented
  in BSD OSes. BSDs are often ahead of GNU/Linux world by many features
  and technologies, of proven quality and stability.

* DNS: https://www.privacyguides.org/advanced/dns-overview/
  Mostly everything is written correctly. However they claim that
  "unencrypted DNS always uses UDP" -- that is just not true, because
  big queries may initiate TCP connection too. I will nag that you do
  not need *encryption* to make your data unmodifiable. DNSSEC
  records are not encrypted, but they can not be modified without
  revealing that fact

* Tor: https://www.privacyguides.org/advanced/tor-overview/
  They write that Tor is decentralized network. This is lie. It is
  distributed, yes, but centralized -- they have got centralized
  closed-source database servers keeping the state of all nodes and
  censoring who can participate in the network (that already happened
  several times). They claim that it is designed "with as much privacy
  as possible" -- can not agree there too, because technically they
  contain *very* primitive technologies, especially comparing to I2P
  project as an example. Powerful adversary, like government, can
  deanonymize Tor participants by monitoring network activities in Tor.
  I2P really tries to hide timing information by using "garlic" packet
  assembling and two unidirectional channels with independent network paths.

  And although I was high-bandwidth Tor exit-node for years, having
  multiple accidents and interrogations with local police forces, I
  changed my mind about that network and strongly against supporting
  that network. As with BitTorrent, I am convinced that it is unfair to
  use it without participating back (by starting up relay node), without
  sharing your resources too. And I am united in solidarity with
  https://withblue.ink/2020/11/12/maybe-we-shouldnt-want-a-fully-decentralized-web.html
  article, where you have to think about ethical questions, about the
  responsibility. For me, Tor is a censorship-bypassing technology
  mainly for spreading the propaganda.

* Page about centralized, federated and peer-to-peer network topologies
  is pretty good indeed: https://www.privacyguides.org/advanced/communication-network-types/
  And I like that they do not bias the reader to any type. Each of them
  has their pros and cons. Even centralized Signal could be the best
  choice for many people. Personally I am fan of federated networks.

* "Linux" choices: https://www.privacyguides.org/linux-desktop/
  They recommend Fedora, openSUSE... but are not this website is solely
  about privacy protection? I assume that they treat any GNU/Linux
  distribution as already much better choice than either Microsoft
  Windows, or Apple macOS. But that is not true and looks like just
  harmful advice. Fedora, Ubuntu and similar widespread distributions
  are not differ much from any of non-free OSes: by default they tend to
  automatically and transparently deanonymize you (of course for your
  better user experience), to leak your search queries, to leak mistyped
  commands, to easily run non-free software (Flatpack, Snappy
  technologies) out-of-box. Every time I have installed and run any of
  those distributions (to check some of my software buildability and
  workability under them) -- each damn time I find many bugs and awful
  overall quality and stability. Latest Fedora is so damn slow and
  bloated, that it can hardly even boot from not so fast USB flash
  drive, leading to timeouts and programs to exit.

  How any of those distributions can be secure, when they contain a
  biggest pile of crap (yes, I intentionally emphasize my worst attitude
  to that terrible anti-Unix mess of bugs and inflexibilities) called
  systemd? Its authors once decided even to hard-code Google's public
  nameservers -- no privacy-aware person can allow that step possibility.
  https://suckless.org/sucks/systemd/

  I really treat systemd-driven distributions no better than any of
  Microsoft/Apple proprietary creations. The same experience, same
  insecurity, same snake-oil with beautiful (meaningless in practice)
  words about the importance of user's privacy.

  However mention of NixOS is a good one. That distribution has very
  interesting and attractive package system with reproducible builds.

* Router distributions: https://www.privacyguides.org/router/
  Can not comment anything here, because I have never used any
  specialized router software. I have always had just an ordinary OS
  installed for that task on separate computer. However I dealt with
  m0n0wall, that is base for pfSense, that is base for OPNsense and can
  not say anything against it. If it is more convenient to you, then why not?

* DNS recommendation: https://www.privacyguides.org/dns/
  Awful and pretty harmful recommendation is using some huge network
  like Cloudflare. Instead of your ISP collecting the DNS data, you
  move that collection to the huge world-wide company, just helping
  privacy-hating corporations to spy on you more easily. It is the same
  as to use Facebook solely for all actions. For example I completely
  (once again) distrusted Firefox, when they enabled DoH feature by
  default, leading millions of users to leak their DNS queries to one of
  the biggest companies in the world. Completely unacceptable and insane.

  Another option they misses: just setting up your own DNS recursive
  resolver on VPS (that are very cheap nowadays) and setting ordinary
  IPsec/WireGuard tunnel to secure requests/responses to it, without
  using specialized unnecessary higher level protocols for that task.

* Email provider recommendation: https://www.privacyguides.org/email/
  Actually that is the most hated page by me. Considering ProtonMail
  completely depreciates any value of the whole website, because it is
  total snake-oil.

  First of all, what does email provider intended to do? It is just
  always available server that temporary stores some outgoing
  correspondence from you, until destination server is available and
  receives it. And it stores incoming correspondence probably long-term,
  until you receive it with you mail user agent (MUA). Email ecosystem
  does not require connections between email providers to be encrypted
  and authenticated. In practice many of them does not support that at
  all. And noone can force TLS usage, because there just can not exist
  common trust anchor for their authentication (geopolitics and so on).
  So you can never be sure that your email correspondence is passed over
  encrypted/authenticated transports solely. That is why you can only do
  end-to-end encryption for assuring correspondence confidentiality.

  Who can be responsible for encryption and authentication while you
  communicate with other people? I assume that this is obvious that only
  *you* can be that responsible person, because only you (and whom you
  talk to) is interested in that. And of course technically encryption
  and authentication can be done in a trusted way only on the computer
  controlled by you. If computer is not under your control -- no privacy
  and security can be expected. If third-party does encryption/authentication
  instead of you -- the same applies.

  So again, what could you expect from email provider? Actually just a
  reliable work with enough storage. You can neither force, nor expect
  it to use encrypted transport. And your encryption/authentication,
  that is done on you computer, does not require any support from the
  provider. So there is practically no difference between any of email
  providers from security point of view if you REALLY do end-to-end
  secure communications. Some of email providers require you to give
  real world identities, some of them require cellphone number binding.
  But in general they are just temporary buffers in the network, nothing
  more.

  I heard that ProtonMail did not provide ability to use SMTP/POP3/IMAP4
  on free accounts. That means that you can not use ordinary MUA on the
  computer under your control. So their free account just can not be
  used for secure communications. They offer (offered?) only web-based
  access, that requires you to run some automatically downloaded
  software from their server (JavaScript code inside the browser).

  The most awful thing is that they provide OpenPGP functionality based
  on that JavaScript code. That means that your computer runs *their*
  software (that can be changed anytime without you notice that fact).
  Complete understanding of some data channel insecurity -- is ok. But
  false sense of security (when you believe about security, but that can
  be false assumption) is much worse: you can not make adequate risk
  management. And ProtonMail just gives exactly the fail sense of
  security. Even if your private key is kept in encrypted form on their
  server and is decrypted only inside your browser, nothing prevents
  them to slightly modify the code *you* run in your browser to make
  your key/message/whatever leaked.

  EVERYTHING that relies on code running inside your browser, that is
  downloaded from remote server not under your control -- can not be
  trusted and you literally has no control over your computer.

  I did not read/check about other email providers, because either it is
  the same snake-oil, or just irrelevant from security point of view.

  I can not comment anything about self-hosting email section, because
  it relies on assumption that you would use webmail solution, that is
  just can not be (securely) compatible with OpenPGP in a sane way.
  Email has to be used through MUA.

* Disk encryption: https://www.privacyguides.org/encryption/
  It is pure insanity to recommend BitLocker. Ok, that is already
  insanity to use Windows and expect any kind of security from it, but
  BitLocker is known (https://media.ccc.de/v/35c3-9671-self-encrypting_deception)
  just to silently bypass encryption and rely on built-in SSD methods,
  that are known often to be complete snake-oil.

There are much information about various software. There are many
proprietary closed-source non-free ones, so, again, shame on that
resource -- non-free software never can be a choice regarding security
or privacy. Of course there are good software mentioned too, like
Syncthing, Mutt, GnuPG and similar things. But considering non-free or
JavaScript-driven solutions brings a false sense of security, that is
much worse than adequate understanding of lack of security.

8 years agoPublished my new out-of-date article about GoVPN internals
Sergey Matveev [Sun, 13 Mar 2016 10:16:53 +0000 (13:16 +0300)]
Published my new out-of-date article about GoVPN internals

http://blogs.fsfe.org/stargrave/archives/158

8 years agoBlog creation
Sergey Matveev [Sun, 17 Jan 2016 12:26:39 +0000 (15:26 +0300)]
Blog creation

I decided to try blog creation, some kind of diary. It is based on
simple Git commits and their Web-interface rendering. It allows quickly
and conveniently make posts through the command line, without online
network access. cgit provides out-of-box Atom (RSS) feeds, that is
must-have for the blog. And I can add various files in the context of
single commit.