This is really hard to maintain when adding new or altering existing
providers.
Reference #12415.
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
fix: EDIPARTYNAME NULL pointer de-reference (CVE-2020-1971)
Severity: High
The X.509 GeneralName type is a generic type for representing different types
of names. One of those name types is known as EDIPartyName. OpenSSL provides a
function GENERAL_NAME_cmp which compares different instances of a GENERAL_NAME
to see if they are equal or not. This function behaves incorrectly when both
GENERAL_NAMEs contain an EDIPARTYNAME. A NULL pointer dereference and a crash
may occur leading to a possible denial of service attack.
OpenSSL itself uses the GENERAL_NAME_cmp function for two purposes:
1) Comparing CRL distribution point names between an available CRL and a CRL
distribution point embedded in an X509 certificate
2) When verifying that a timestamp response token signer matches the timestamp
authority name (exposed via the API functions TS_RESP_verify_response and
TS_RESP_verify_token)
If an attacker can control both items being compared then that attacker could
trigger a crash. For example if the attacker can trick a client or server into
checking a malicious certificate against a malicious CRL then this may occur.
Note that some applications automatically download CRLs based on a URL embedded
in a certificate. This checking happens prior to the signatures on the
certificate and CRL being verified. OpenSSL's s_server, s_client and verify
tools have support for the "-crl_download" option which implements automatic
CRL downloading and this attack has been demonstrated to work against those
tools.
Note that an unrelated bug means that affected versions of OpenSSL cannot parse
or construct correct encodings of EDIPARTYNAME. However it is possible to
construct a malformed EDIPARTYNAME that OpenSSL's parser will accept and hence
trigger this attack.
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
This line was accidentially messed up while merging two patchsets
together, causing tor.cgi to crash with an HTTP error 500 in testing.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
The get_full_country_name() function had an accidenlty and not longer
required call of the DB init function.
This is a waste of memory and a known problem, especially on systems
with less than 1GB of RAM, where the application which uses libloc in
such a redundant way crashes.
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Otherwise the WUI is not allowed to put and release the nobeep file in
this folder and the desired functionality does not work.
Fixes#12385.
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This patch disables the output of 'iptables' in 'summary.dat' by
modifying '/usr/share/conf/logwatch.conf'.
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This improves the usability of the zone configuration by marking assigned
NICs in the zone color. The highlighting is initially applied to the static
HTML output, and JavaScript is used to follow changes made by the user.
Signed-off-by: Leo-Andres Hofmann <hofmann@leo-andres.de>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- Add an element id so that the styling only affects the zone table
- Alternating row colors are now generated by CSS, remove unneeded Perl code
Signed-off-by: Leo-Andres Hofmann <hofmann@leo-andres.de>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This fixes two minor violations of the HTML standard:
- <a> elements may not contain nested <button> elements:
Replace the button with a simple hyperlink, because it was only used as a link anyway.
- "id" attributes may not contain whitespace:
Remove unneeded attribute, use hyphens instead of spaces.
Signed-off-by: Leo-Andres Hofmann <hofmann@leo-andres.de>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
OpenVPN is an absolute mess. The behaviour of configuration
parameters has been changed over the time; default values have been
changed over time; and it looks like nobody is actually testing
anything any more.
I have been spending hours today on figuring out why OpenVPN
is so damn slow. On a Lightning Wire Labs IPFire Mini Appliance
it achieves about 100 MBit/s in the default configuration when
"openssl speed -evp aes-256-gcm" achieves over 3.5 GBit/s.
Changing any of the cryptography parameters does not change
anything. Throughput remains around 100 MBit/s.
I finally set "cipher none" and "auth none" which disables
encryption and authentication altogether but does not increase
throughput. From here on it was absolutely clear that it was
not a crypto issue.
OpenVPN tries to be smart here and does its own fragmentation.
This is the worst idea I have heard of all day, because that job
is normally done best by the OS.
Various settings which allow the user to "tune" this are grossly
ineffective - let alone it isn't even clear what I am supposed
to configure anywhere. Setting "fragment 1500" weirdly still
does not convince openvpn to generate a packet that is longer
than 1400 bytes. Who'd a thunk?
There is a number of other parameters to set the MTU or which
are related to it (tun-mtu, link-mtu, fragment, mssfix).
On top of all of this we have two "bugs" in ovpnmain.cgi which
are being fixed in this patch:
1) mssfix can be configured by the user. However, we always
enable it in openvpn. The default is on, we only add "mssfix"
which simply turns it on.
It is now being disabled when the user has chosen so in the
web UI. I do not know if this is backwards-compatible.
2) We cap the MTU (tun-mtu) at 1500 bytes when fragment is being
used. So it becomes pointless that the user can this and the
user is not being made aware of this when they hit the save
button.
This was added when we added path MTU discovery. Since that
did not work and was removed, we can remove this now, too.
I archived a solid 500-600 MBit/s of goodput with these settings:
* Disable mssfix
* Set "fragment" to 0
* Set MTU to 9000
I am sure the MTU could be further increased to have bigger packets,
but I did not test how badly this will affect latency of the tunnel.
OpenVPN seems to only be able to handle a certain amount of packets
a second - no matter what. With larger packets, the throughput of
the tunnel increases, but latency might as well.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Cc: Erik Kapfer <erik.kapfer@ipfire.org>
Cc: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
In order to make deanonymisation harder, especially high-risk Tor users
might want to use certain Guard relays only (for example operated by
people they trust), enforce Tor to use Guard relays in certain countries
only (for example countries with very strict data protection laws or
poor diplomatic relations), or avoid Guard relays in certain countries
entirely.
Since Tor sticks to sampled Guards for a long time (usually within the
range of months), restricting those is believed to cause less harm to a
users' anonymity than restricting Exit relays, since their diversity of
a generic Tor user is significantly higher.
This patch extends the Tor CGI for restricting Guard nodes to certain
countries or relays matching certain fingerprints.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This extends the functionality of the Tor CGI in order to be able to
select multiple countries for possible Exit relays, which is - in terms
of anonymity - less worse than limiting all Tor circuits to a single
country.
For example, a user might want to avoid Exit relays in more than one
country, and permit Tor to use Exit relays elesewhere, and vice versa.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
