Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.58.8

http-tls-allow-sslv3

Globaldeprecatedrestart required

Whether to accept SSLv3 on the web monitor — the directive has no effect
in the configuration this is a linehttp-tls-allow-sslv3inside the block Global
The fifth copy of a line that does nothing

Like its namesakes for sending, receiving, the listener and the Transmissions API input, the line is not valid: the protocol is not in the distribution.

A configuration may contain five such lines, and all five are to be deleted — the node’s behavior will not change.

On the monitor it is more conspicuous than the others. The management interface is the first to appear in security reports, and the line http-tls-allow-sslv3 false reads there as a protective measure taken. It is not a measure.

The main trap is taking the line for an effective setting. It causes no error and looks like an ordinary prohibition; in security configuration reports it regularly appears as “prohibition of an insecure protocol”.
What the Hub does. It does not write it — and could not: there is no protocol support.
Recommended values

There are no values. The only action is to remove it:

What was found What to do
http-tls-allow-sslv3 delete
the same lines for sending, receiving, the listener and the API input delete too
other http-tls-allow-* next to it rewrite as a pair of bounds
The fact that the directive is no longer valid is from the manual (§ 3.3.1.58.8). The advice to delete all five copies is ours.
Example configuration
# it should not be like this — the line does nothing
http-mgmt-port 1000
http-tls-allow-sslv3 false
Found in migrated configurations. Deleting it will not change behavior: the protocol is not in the distribution.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends1 mistake▶

Considering the line an effective protection of the management interface

§ 3.3.1.58.8

What it costsIt looks like a prohibition of an insecure protocol and ends up in security reports. In fact it does nothing, and the real lower bound stays as it was.
How to spot itThe line is listed among protective measures in a configuration audit.
How to do it rightRemove it and rely on http-tls-min-version: it is the only working way to set the monitor’s lower bound.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
Reference data
Syntax
http-tls-allow-sslv3 <boolean>
Values
values are not applied — the directive has no effect
Applying
a service restart is required
Queue
will not touch what is already queued
Where to write it
Global
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
There is no inheritance to discuss: the line has no effect. The lower bound that replaces it is written in the same place, at the root of the file, and applies to the node’s whole management interface.
How to check on the node
There is one check — find all five copies and remove them:
grep -rn "tls-allow-sslv3" /etc/pmta/
Lines for sending, receiving by the node, the listener, the Transmissions API input and the web monitor will be found. All are to be deleted.
In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Node security