Re: [AusNOG] Issues receiving from TPG Mail servers.

[Bradley Silverman]

Thanks everyone for your assistance, I just wanted to let you all know that
email from TPG's mail servers has started flowing in.

Big thanks to TPG for sorting that out and have a good weekend everyone,
drinks all round!

Regards,

Bradley Silverman | VentraIP Australia
*Technical Operations*

mobile. +61 418 641 103
phone. +61 3 9013 8464

On Tue, Jul 24, 2018 at 3:53 PM, Roy Adams  wrote:

> For those stuck in the blat.exe land forced to use tcp/25 , I moved to
> mailsend recently and have not looked back
> https://sourceforge.net/projects/mailsend.mirror/
>
> Works great with Google Free, GSuite, Outlook Free, and Office 365
> To save people reinventing the wheel, I have pasted below a cmd script I
> wrote to act as a shell for whatever I need to email.
> It's basically a wrapper.. of sorts
> Note, it doesn't use the -attach option in this example.
> You can specify -attach as many times as you need in a single command line
> run to attach multiple files
>
> It also writes so the event log.
> *If you cannot read it, do not run it :)*
>
> Comments welcomed, but no responsibility accepted of course :)
>
>
> Kindly,
>
> ROY ADAMS* | *P 07 3040 5010  | Web: http://www.racs.com.au/ | Wiki:
> https://ex.racs.com.au:444/ | eMail: mailto:r...@racs.com.au
> 
> Please never upgrade to the latest Windows 10 - You don’t need the hassle,
> and I don’t need the work.
> If you think it's expensive to hire a professional to do the job, wait
> until you hire an amateur - Red Adair.
> Life is a journey through a series of adventures.. Live them, love them,
> hate them, but never give up on your dreams, desires, and goals.
>
>
>
>
>
> @echo off
> :: MailSend.EXE - https://github.com/muquit/mailsend/
> :: GZIP.EXE - http://gnuwin32.sourceforge.net/packages/gzip.htm
> :: forfiles.exe - Windows Vista and above. Windows XP does not have this -
> get it from somewhere
> :: @set GNUToolDir= - you can set this if you wish manually - IT MUST HAVE
> TRAILING BACKSLASH - and comment/delete the detection stuff after it - e.g.
> set GNUToolDir=C:\Utils\
> :: %1 = IP Address of SMTP server THAT ALLOWS RELAY
> :: %2 = SMTP Address to send Errors and Summaries
> ::
> :: Google SMTP settings:
> :: SMTP: smtp.gmail.com, port 587 (TLS) or port 465 (SSL)
> :: Google 2-factor auth App-Specific Passwords -
> https://security.google.com/settings/security/apppasswords
> :: Microsoft SMTP settings:
> :: SMTP: smtp-mail.outlook.com port 587 (TLS) - outlook.com free email
> :: SMTP: smtp.office365.com port 587 (TLS) - Office 365 commercial email
> :: Microsoft 2-factor auth App-Specific Passwords -
> https://support.microsoft.com/en-us/help/12409/microsoft-
> account-app-passwords-two-step-verification
>
> @SetLocal
> 1>>NUL: 2>>NUL: eventcreate /l application /t information /so "Script:
> %~n0 Start" /ID 555 /D "Script Start %date% - %time%"
>
> :: *** Set SMTP Server HERE
> @set EmailServer=smtp.gmail.com
> @IF /I "%1" NEQ "" @set EmailServer=%1
>
> :: *** Set Notify SMTP Prefix HERE (without @ or domain suffix)
> @set BackupNotifyUser=%UserName%
>
> :: *** Set Email Send Domain to something real if you are using
> @something.local by default instead of something.com.au
> @set BackupDNSDomain=%UserDNSDomain%
> @set BackupDNSDomain=dss.asia
> @IF /I "2" NEQ "" @for /f "Tokens=2 Delims=@" %%d in ('@echo %2') do @set
> BackupDNSDomain=%%d
>
> :: *** Set Email Address for Notifications/Logs here
> @set EmailTo=%BackupNotifyUser%@%BackupDNSDomain%
> @IF /I "%2" NEQ "" @set EmailTo=%2
>
> @set ServerName=%ComputerName%
> @set SMTPPort=587
> @set EmailNameFrom=xx Sender Friendly Name Goes Here xx
> @set EmailFrom=xxxsenderaddress...@gmail.com
> @set EmailUserName=%EmailFrom%
> @set EmailPassword=XXXpasswordXXX
> @set CompletionStatus=FAILED
> @set CompletionErrorInfo=
> @set ScriptDrive=C:
> @set ScriptPath=\Scripts
> @set ScriptDir=%ScriptDrive%%ScriptPath%\
> @set LogDrive=C:
> @set LogPath=\Logs
> @set LogDir=%LogDrive%%LogPath%\
>
> ::Make sure first our utilities exist - exit if not and write such to the
> event log
> @set GNUToolDir=&@for %%f in (MailSend.exe) do @set GNUToolDir=%%~dp$PATH:f
> @set MailSendExe=&@for %%f in (MailSend.exe) do @set MailSendExe=%%~$PATH:f
> @if /I "%MailSendExe%" EQU "" @set MailSendExe=%GNUToolDir%MailSend.exe
> @if /I not exist "%MailSendExe%" @set 
> CompletionErrorInfo=%CompletionErrorInfo%
> - MailSend.exe missing or not in PATH
> @set GZipExe=&@for %%f in (GZip.exe) do @set GZipExe=%%~$PATH:f
> @if /I "%GZipExe%" EQU "" @set GZipExe=%GNUToolDir%GZip.exe
> @if /I not exist "%GZipExe%" @set CompletionErrorInfo=%CompletionErrorInfo%
> - gzip.exe missing or not in PATH
> @set ForFilesExe=&@for %%f in (ForFiles.exe) do @set ForFilesExe=%%~$PATH:f
> @if /I "%ForFilesExe%" EQU "" @set ForFilesExe=%GNUToolDir%ForFiles.exe
> @if /I not exist "%ForFilesExe%" @set 
> CompletionErrorInfo=%CompletionErrorInfo%
> - ForFiles.exe missing or not in PATH
>
> @if /I "%CompletionErrorInfo%" NEQ "" GOTO FinishError

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Roy Adams]

For those stuck in the blat.exe land forced to use tcp/25 , I moved to
mailsend recently and have not looked back
https://sourceforge.net/projects/mailsend.mirror/

Works great with Google Free, GSuite, Outlook Free, and Office 365
To save people reinventing the wheel, I have pasted below a cmd script I
wrote to act as a shell for whatever I need to email.
It's basically a wrapper.. of sorts
Note, it doesn't use the -attach option in this example.
You can specify -attach as many times as you need in a single command line
run to attach multiple files

It also writes so the event log.
*If you cannot read it, do not run it :)*

Comments welcomed, but no responsibility accepted of course :)


Kindly,

ROY ADAMS* | *P 07 3040 5010  | Web: http://www.racs.com.au/ | Wiki:
https://ex.racs.com.au:444/ | eMail: mailto:r...@racs.com.au

Please never upgrade to the latest Windows 10 - You don’t need the hassle,
and I don’t need the work.
If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur - Red Adair.
Life is a journey through a series of adventures.. Live them, love them,
hate them, but never give up on your dreams, desires, and goals.





@echo off
:: MailSend.EXE - https://github.com/muquit/mailsend/
:: GZIP.EXE - http://gnuwin32.sourceforge.net/packages/gzip.htm
:: forfiles.exe - Windows Vista and above. Windows XP does not have this -
get it from somewhere
:: @set GNUToolDir= - you can set this if you wish manually - IT MUST HAVE
TRAILING BACKSLASH - and comment/delete the detection stuff after it - e.g.
set GNUToolDir=C:\Utils\
:: %1 = IP Address of SMTP server THAT ALLOWS RELAY
:: %2 = SMTP Address to send Errors and Summaries
::
:: Google SMTP settings:
:: SMTP: smtp.gmail.com, port 587 (TLS) or port 465 (SSL)
:: Google 2-factor auth App-Specific Passwords -
https://security.google.com/settings/security/apppasswords
:: Microsoft SMTP settings:
:: SMTP: smtp-mail.outlook.com port 587 (TLS) - outlook.com free email
:: SMTP: smtp.office365.com port 587 (TLS) - Office 365 commercial email
:: Microsoft 2-factor auth App-Specific Passwords -
https://support.microsoft.com/en-us/help/12409/microsoft-account-app-passwords-two-step-verification

@SetLocal
1>>NUL: 2>>NUL: eventcreate /l application /t information /so "Script: %~n0
Start" /ID 555 /D "Script Start %date% - %time%"

:: *** Set SMTP Server HERE
@set EmailServer=smtp.gmail.com
@IF /I "%1" NEQ "" @set EmailServer=%1

:: *** Set Notify SMTP Prefix HERE (without @ or domain suffix)
@set BackupNotifyUser=%UserName%

:: *** Set Email Send Domain to something real if you are using
@something.local by default instead of something.com.au
@set BackupDNSDomain=%UserDNSDomain%
@set BackupDNSDomain=dss.asia
@IF /I "2" NEQ "" @for /f "Tokens=2 Delims=@" %%d in ('@echo %2') do @set
BackupDNSDomain=%%d

:: *** Set Email Address for Notifications/Logs here
@set EmailTo=%BackupNotifyUser%@%BackupDNSDomain%
@IF /I "%2" NEQ "" @set EmailTo=%2

@set ServerName=%ComputerName%
@set SMTPPort=587
@set EmailNameFrom=xx Sender Friendly Name Goes Here xx
@set EmailFrom=xxxsenderaddress...@gmail.com
@set EmailUserName=%EmailFrom%
@set EmailPassword=XXXpasswordXXX
@set CompletionStatus=FAILED
@set CompletionErrorInfo=
@set ScriptDrive=C:
@set ScriptPath=\Scripts
@set ScriptDir=%ScriptDrive%%ScriptPath%\
@set LogDrive=C:
@set LogPath=\Logs
@set LogDir=%LogDrive%%LogPath%\

::Make sure first our utilities exist - exit if not and write such to the
event log
@set GNUToolDir=&@for %%f in (MailSend.exe) do @set GNUToolDir=%%~dp$PATH:f
@set MailSendExe=&@for %%f in (MailSend.exe) do @set MailSendExe=%%~$PATH:f
@if /I "%MailSendExe%" EQU "" @set MailSendExe=%GNUToolDir%MailSend.exe
@if /I not exist "%MailSendExe%" @set
CompletionErrorInfo=%CompletionErrorInfo% - MailSend.exe missing or not in
PATH
@set GZipExe=&@for %%f in (GZip.exe) do @set GZipExe=%%~$PATH:f
@if /I "%GZipExe%" EQU "" @set GZipExe=%GNUToolDir%GZip.exe
@if /I not exist "%GZipExe%" @set CompletionErrorInfo=%CompletionErrorInfo%
- gzip.exe missing or not in PATH
@set ForFilesExe=&@for %%f in (ForFiles.exe) do @set ForFilesExe=%%~$PATH:f
@if /I "%ForFilesExe%" EQU "" @set ForFilesExe=%GNUToolDir%ForFiles.exe
@if /I not exist "%ForFilesExe%" @set
CompletionErrorInfo=%CompletionErrorInfo% - ForFiles.exe missing or not in
PATH

@if /I "%CompletionErrorInfo%" NEQ "" GOTO FinishError

:: Do Stuff Here

@set CompletionStatus=OK
@set CompletionErrorInfo=%CompletionErrorInfo% - Normal End

@"%MailSendExe%" -v -4 -ehlo -auth -starttls -port %SMTPPort% -smtp
%EmailServer% -user %EmailUserName% -pass %EmailPassword% -f %EmailFrom%
-name "%EmailNameFrom%" -t %EmailTo% -mime-type "text/plain" -sub "** -
%ComputerName% - %~n0 Started by %UserName% - **" -M "Hopefully this is the
body"

:FinishError
1>>NUL: 2>>NUL: eventcreate /l application /t information /so "Script: %~n0
End" /ID 555 /D "Finished with Status: %CompletionStatus% - %date% - %time%
- %CompletionErrorInfo%"
@EndLocal
@G

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Scott Howard]

On Mon, Jul 23, 2018 at 10:00 PM, Paul Wilkins 
wrote:

> One thing you might check is the cipher set you're using.
>
> I can connect to https://tpg.com.au with TLS1.2 just fine.
>

What they support on HTTPS/port 443 isn't all that relevant for email
delivery...


> openssl s_client -connect mx1.tpgi.com.au:465
>

Again the original thread was about receiving emails, so port 465 plays no
part.  In fact, there's no way to explicitly test what they support when
sending emails (other than actually having them send an email and watching,
obviously), but he nearest would be to see what their MX records support on
port 25.

The command to test that would be :
$ openssl s_client -connect mx1.tpgi.com.au:25 -starttls smtp -tls1_2

which fails as they don't support TLS 1.2.  The same command for TLS1.1
also fails, whilst TLS1.0 succeeds.
(This presumes they use the same systems/config for inbound as outbound,
but that's generally a fairly safe bet)

  Scott
___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Scott Howard]

On Mon, Jul 23, 2018 at 9:45 PM, Bradley Silverman <
bsilver...@staff.ventraip.com> wrote:

> It isn't possible to set TLSv1.0 for un-authenticated email, and TLSv1.1
> for authenticated, though that would fix the problem.
>

Yes, it is.

The problem is you're trying to use port 25 for both delivery
("unauthenticated") and submission ("authenticated")

Move your "authenticated" email over to port 587 where it belongs.  Not
only will this allow you to solve your problems, but will also solve any
future potential issues with people blocking port 25 (eg, home ISPs)

  Scott
___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Peter Tonoli]

Quoting Paul Wilkins :


One thing you might check is the cipher set you're using.

I can connect to https://tpg.com.au with TLS1.2 just fine.

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, 256 bit keys, TLS1.2

Output of following can usually highlight problems:

openssl s_client -connect mx1.tpgi.com.au:465
or
curl -v smtps://mx1.tpgi.com.au:465


The issue with TLS 1.2 is that it's susceptible to a downgrade attack,  
therefore bringing it down to 1.1/1.0/SSL3.


Cheers,
Peter.

___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Ted Cooper]

On 24/07/18 15:22, Mark Foster wrote:
> Oh good. Port 465. Another Depreciated thing :-)
> 
> https://stackoverflow.com/questions/15796530/what-is-the-difference-between-ports-465-and-587
> 
> There's no longer a reason to offer services on Port 465 :S
> 
> Not really relevant to the OP problem, but I couldn't not-bite...

No fear, it was recently de-deprecated and is now considered standard again.

https://tools.ietf.org/html/rfc8314

> 7.3.  Submissions Port Registration
> 
>IANA has assigned an alternate usage of TCP port 465 in addition to
>the current assignment using the following template [RFC6335]:
> 
>  Service Name: submissions
>  Transport Protocol: TCP
>  Assignee: IESG 
>  Contact: IETF Chair 
>  Description: Message Submission over TLS protocol
>  Reference: RFC 8314
>  Port Number: 465
> 
>This is a one-time procedural exception to the rules in [RFC6335].
>This requires explicit IESG approval and does not set a precedent.
>Note: Since the purpose of this alternate usage assignment is to
>align with widespread existing practice and there is no known usage
>of UDP port 465 for Message Submission over TLS, IANA has not
>assigned an alternate usage of UDP port 465.
> 
>Historically, port 465 was briefly registered as the "smtps" port.
>This registration made no sense, as the SMTP transport MX
>infrastructure has no way to specify a port, so port 25 is always
>used.  As a result, the registration was revoked and was subsequently
>reassigned to a different service.  In hindsight, the "smtps"
>registration should have been renamed or reserved rather than
>revoked.  Unfortunately, some widely deployed mail software
>interpreted "smtps" as "submissions" [RFC6409] and used that port for
>email submission by default when an end user requested security
>during account setup.  If a new port is assigned for the submissions
>service, either (a) email software will continue with unregistered
>use of port 465 (leaving the port registry inaccurate relative to

___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Mark Foster]

Oh good. Port 465. Another Depreciated thing :-)

https://stackoverflow.com/questions/15796530/what-is-the-difference-between-ports-465-and-587

There's no longer a reason to offer services on Port 465 :S

Not really relevant to the OP problem, but I couldn't not-bite...

Mark.

> One thing you might check is the cipher set you're using.
>
> I can connect to https://tpg.com.au with TLS1.2 just fine.
>
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, 256 bit keys, TLS1.2
>
> Output of following can usually highlight problems:
>
> openssl s_client -connect mx1.tpgi.com.au:465
> or
> curl -v smtps://mx1.tpgi.com.au:465
>


*snip*

Mark.

___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Paul Wilkins]

One thing you might check is the cipher set you're using.

I can connect to https://tpg.com.au with TLS1.2 just fine.

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, 256 bit keys, TLS1.2

Output of following can usually highlight problems:

openssl s_client -connect mx1.tpgi.com.au:465
or
curl -v smtps://mx1.tpgi.com.au:465

Kind regards

On 24 July 2018 at 14:45, Bradley Silverman 
wrote:

> I think I am still doing a poor job of explaining the scenario clearly,
> which is making everyone go off track with this.
>
> We can receive emails from MTAs and the like, without any authentication,
> without TLS. That is perfectly fine and PCI compliant.
> IF authentication is required (like users sending email with us as *their* 
> outgoing
> server), then TLSv1.1 or higher is required. That's because confidential
> credentials are being sent, the username and password specifically.
>
> It isn't possible to set TLSv1.0 for un-authenticated email, and TLSv1.1
> for authenticated, though that would fix the problem.
> If TPG were using TLS1.1 OR sending without TLS at all, everything would
> be perfectly fine.
>
> While I agree that TPG aren't doing the 'wrong' thing, they are using a
> protocol that is almost 20 years old and generally considered not secure.
>
> We got some great details to get in touch with them (thanks for that) and
> we are working towards a solution. Thanks to everyone for responding and
> have a great day!
>
> Regards,
>
> Bradley Silverman | VentraIP Australia
> *Technical Operations*
>
> mobile. +61 418 641 103
> phone. +61 3 9013 8464
>
> On Tue, Jul 24, 2018 at 1:59 PM, Scott Howard  wrote:
>
>> My take would be that for a general service provider, like TPG, you
>> should be as accepting as possible. That would including accepting clear
>> text and TLS 1.0 (although possibly not SSLv3).  Any specific sender or
>> recipient can enforce stronger limitations if they choose to do so.
>>
>> For a provider that has any focus on security it's potentially a
>> different story. In that case enforcing TLS1.2 potentially makes sense,
>> although it the raises the question around what you do with servers that
>> don't support TLS at all, or like TPG at the moment, don't support TLS
>> higher than 1.0 (is cleartext better than TLS1.0?)
>>
>> Then there's the elephant in the room when it comes to SMTP around
>> certificate verification, and if/how you determine your talking to the
>> correct mail server (at which point you have to move the conversation over
>> to things like DNSSEC)
>>
>>   Scott
>>
>>
>>
>> On Tue, Jul 24, 2018, 09:48 Paul Wilkins 
>> wrote:
>>
>>> Should TLS 1.0 be acceptable?
>>>
>>> I don't claim to be a crypto geek.
>>>
>>> Curiously the ISM standards make TLS 1.2 only advisory:
>>>
>>>
>>>- Control: 1447; Revision: 0; Updated: Apr-15; Applicability: UD, P,
>>>C, S, TS; Compliance: must; Authority: AA
>>>   - Agencies *must use TLS*.
>>>   -
>>>   - Control: 1139; Revision: 3; Updated: Apr-15; Applicability: UD,
>>>P, C, S, TS; Compliance: should; Authority: AA
>>>   - Agencies *should use the latest version of TLS*
>>>
>>> Kind regards
>>>
>>> Paul Wilkins
>>>
>>> On 24 July 2018 at 11:10, Scott Howard  wrote:
>>>
 On Mon, Jul 23, 2018 at 6:00 PM, Noel Butler 
 wrote:
>
> You are the one choosing to use cpanel/plesk, lazy webhost solutions
> that puts all your customers eggs in the one single basket (though I heard
> plesk may soon be changing that), sorry, but that is not TPG's fault your
> chosen hosting software lives in the 90s.
>

 Perhaps not, but it IS TPG's fault that their mail server is only
 supporting encryption algorithms that live in the 90's...

 Irrespective of the PCI argument or not, TPG supporting TLS 1.0 but not
 higher in 2018 simply shouldn't be seen as acceptable.

   Scott


 ___
 AusNOG mailing list
 AusNOG@lists.ausnog.net
 http://lists.ausnog.net/mailman/listinfo/ausnog


>>> ___
>>> AusNOG mailing list
>>> AusNOG@lists.ausnog.net
>>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>>
>>
>> ___
>> AusNOG mailing list
>> AusNOG@lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>>
>
___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Bradley Silverman]

I think I am still doing a poor job of explaining the scenario clearly,
which is making everyone go off track with this.

We can receive emails from MTAs and the like, without any authentication,
without TLS. That is perfectly fine and PCI compliant.
IF authentication is required (like users sending email with us as
*their* outgoing
server), then TLSv1.1 or higher is required. That's because confidential
credentials are being sent, the username and password specifically.

It isn't possible to set TLSv1.0 for un-authenticated email, and TLSv1.1
for authenticated, though that would fix the problem.
If TPG were using TLS1.1 OR sending without TLS at all, everything would be
perfectly fine.

While I agree that TPG aren't doing the 'wrong' thing, they are using a
protocol that is almost 20 years old and generally considered not secure.

We got some great details to get in touch with them (thanks for that) and
we are working towards a solution. Thanks to everyone for responding and
have a great day!

Regards,

Bradley Silverman | VentraIP Australia
*Technical Operations*

mobile. +61 418 641 103
phone. +61 3 9013 8464

On Tue, Jul 24, 2018 at 1:59 PM, Scott Howard  wrote:

> My take would be that for a general service provider, like TPG, you should
> be as accepting as possible. That would including accepting clear text and
> TLS 1.0 (although possibly not SSLv3).  Any specific sender or recipient
> can enforce stronger limitations if they choose to do so.
>
> For a provider that has any focus on security it's potentially a different
> story. In that case enforcing TLS1.2 potentially makes sense, although it
> the raises the question around what you do with servers that don't support
> TLS at all, or like TPG at the moment, don't support TLS higher than 1.0
> (is cleartext better than TLS1.0?)
>
> Then there's the elephant in the room when it comes to SMTP around
> certificate verification, and if/how you determine your talking to the
> correct mail server (at which point you have to move the conversation over
> to things like DNSSEC)
>
>   Scott
>
>
>
> On Tue, Jul 24, 2018, 09:48 Paul Wilkins  wrote:
>
>> Should TLS 1.0 be acceptable?
>>
>> I don't claim to be a crypto geek.
>>
>> Curiously the ISM standards make TLS 1.2 only advisory:
>>
>>
>>- Control: 1447; Revision: 0; Updated: Apr-15; Applicability: UD, P,
>>C, S, TS; Compliance: must; Authority: AA
>>   - Agencies *must use TLS*.
>>   -
>>   - Control: 1139; Revision: 3; Updated: Apr-15; Applicability: UD,
>>P, C, S, TS; Compliance: should; Authority: AA
>>   - Agencies *should use the latest version of TLS*
>>
>> Kind regards
>>
>> Paul Wilkins
>>
>> On 24 July 2018 at 11:10, Scott Howard  wrote:
>>
>>> On Mon, Jul 23, 2018 at 6:00 PM, Noel Butler 
>>> wrote:

 You are the one choosing to use cpanel/plesk, lazy webhost solutions
 that puts all your customers eggs in the one single basket (though I heard
 plesk may soon be changing that), sorry, but that is not TPG's fault your
 chosen hosting software lives in the 90s.

>>>
>>> Perhaps not, but it IS TPG's fault that their mail server is only
>>> supporting encryption algorithms that live in the 90's...
>>>
>>> Irrespective of the PCI argument or not, TPG supporting TLS 1.0 but not
>>> higher in 2018 simply shouldn't be seen as acceptable.
>>>
>>>   Scott
>>>
>>>
>>> ___
>>> AusNOG mailing list
>>> AusNOG@lists.ausnog.net
>>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>>
>>>
>> ___
>> AusNOG mailing list
>> AusNOG@lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>
> ___
> AusNOG mailing list
> AusNOG@lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Scott Howard]

My take would be that for a general service provider, like TPG, you should
be as accepting as possible. That would including accepting clear text and
TLS 1.0 (although possibly not SSLv3).  Any specific sender or recipient
can enforce stronger limitations if they choose to do so.

For a provider that has any focus on security it's potentially a different
story. In that case enforcing TLS1.2 potentially makes sense, although it
the raises the question around what you do with servers that don't support
TLS at all, or like TPG at the moment, don't support TLS higher than 1.0
(is cleartext better than TLS1.0?)

Then there's the elephant in the room when it comes to SMTP around
certificate verification, and if/how you determine your talking to the
correct mail server (at which point you have to move the conversation over
to things like DNSSEC)

  Scott



On Tue, Jul 24, 2018, 09:48 Paul Wilkins  wrote:

> Should TLS 1.0 be acceptable?
>
> I don't claim to be a crypto geek.
>
> Curiously the ISM standards make TLS 1.2 only advisory:
>
>
>- Control: 1447; Revision: 0; Updated: Apr-15; Applicability: UD, P,
>C, S, TS; Compliance: must; Authority: AA
>   - Agencies *must use TLS*.
>   -
>   - Control: 1139; Revision: 3; Updated: Apr-15; Applicability: UD,
>P, C, S, TS; Compliance: should; Authority: AA
>   - Agencies *should use the latest version of TLS*
>
> Kind regards
>
> Paul Wilkins
>
> On 24 July 2018 at 11:10, Scott Howard  wrote:
>
>> On Mon, Jul 23, 2018 at 6:00 PM, Noel Butler 
>> wrote:
>>>
>>> You are the one choosing to use cpanel/plesk, lazy webhost solutions
>>> that puts all your customers eggs in the one single basket (though I heard
>>> plesk may soon be changing that), sorry, but that is not TPG's fault your
>>> chosen hosting software lives in the 90s.
>>>
>>
>> Perhaps not, but it IS TPG's fault that their mail server is only
>> supporting encryption algorithms that live in the 90's...
>>
>> Irrespective of the PCI argument or not, TPG supporting TLS 1.0 but not
>> higher in 2018 simply shouldn't be seen as acceptable.
>>
>>   Scott
>>
>>
>> ___
>> AusNOG mailing list
>> AusNOG@lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>>
> ___
> AusNOG mailing list
> AusNOG@lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Chad Kelly]

On 7/24/2018 12:00 PM, ausnog-requ...@lists.ausnog.net wrote:


I would be surprised if any shared/public hosting environment can also
deliver PCI compliance as a result. Dedicated tin ensuring segregation
between your systems and those of $RANDOM_STRANGER is required.
Or have we forgotton meltdown/spectre?

Shared hosting by itself is not PCI compliant.
You can't store credit / debit card info on a shared server even with an 
SSL certificate.
You can however use a payment gateway such as Eway to collect the info 
required and handle payments or Paypal is the other option or any number 
of other solutions.
Unless the organisation is ISO 27001 certified they shouldn't even think 
of storing payment info that isn't counting the money you need to spend 
on the PCI DSS side of things.
I'd just ban anyone from storing card info on the server as its way too 
much of a security risk think what happened to Cyanweb.com.au when they 
were brute forced and the hackers destroyed the lot including the 
billing system.


--
Chad Kelly
Manager
CPK Web Services
Phone 03 5273 0246
Web www.cpkws.com.au

___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Mark Foster]

>
>
> On 24/07/2018 6:54 AM, Mark Foster wrote:
>
>>> Un-authenticated mail, however, doesn't require credentials in order to
>>> accept mail, however, unless that server is relay, it also won't pass
>>> that
>>> mail on. It would only accept mail from a server if the mailbox was
>>> actually on it. So when a sending MTA sends mail to us, our server will
>>> accept it if the email account is on that server.
>>> This *doesn't* require authentication and thus no username or password
>>> are
>>> supplied. As such encryption isn't required because there are no
>>> details
>>> to
>>> steal, unless as someone pointed out, you're silly enough to send
>>> credit
>>> card details via email.
>>
>> ... and if you are sending or receiving email from the world-at-large
>> (thus, unauthenticated, as you put it) then you can't mandate
>> encryption,
>> true.
>
> This is simply incorrect.  You can mandate encryption for transport
> layer security with DANE.  This migrates opportunistic TLS into
> mandatory, as required.
>
> No usernames are required !  :)
>
> Postfix (MTA) supports DANE and tls_policy maps can be configured to
> ensure 'partner' domains are communicated via secure channel only.
> Should the remote partner not have suitable TLSA records, the connection
> will soft-fail until the remote end is corrected.  This guarantees that
> an encrypted connection will be used, provided the remote party offers
> StartTLS / DNSSEC / publishes TLSA records.
>
> For other domains not associated with the PCI connection domain (the
> remote partner you want to ensure encryption with), opportunistic TLS
> applies, if supported by the remote end, per any normal email
> transmission.
>
>

Just for clarity, I wasn't meaning to suggest that it wasn't technically
possible to 'mandate' the use of encryption for email transport.  Just
that it's not something you can force others into doing. It's either your
own platform, or you establish a commercial agreement which is mutually
agreed and both parties have some level of incentive to fix it.

Or, you simply accept you won't be moving email between your servers, if
you choose to implement something like the above in order to achieve some
sort of box-ticking compliance-with-a-standard certification.

It'd be lovely to see TPG join us in the current decade, but i'm not
holding my breath.  I'm still prepared to be surprised, however :-)

Mark.

___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Mark Foster]

As a point of comparison, the NZISM (yes, i'm a kiwi) stipulations are
similar:

https://www.nzism.gcsb.govt.nz/ism-document#2521

17.4.16.C.01.
Control:  System Classification(s): All Classifications; Compliance:
SHOULD [CID:2598]

Agencies SHOULD use the current version of TLS (version 1.2).

NZISM also notes that TLS 1.2 was launched in 2008.

So I agree that TPG are clearly miles behind the ball if they're not even
yet operating to a 10 year old update to the RFC.

Mark.

> Should TLS 1.0 be acceptable?
>
> I don't claim to be a crypto geek.
>
> Curiously the ISM standards make TLS 1.2 only advisory:
>
>
>- Control: 1447; Revision: 0; Updated: Apr-15; Applicability: UD, P, C,
>S, TS; Compliance: must; Authority: AA
>   - Agencies *must use TLS*.
>   -
>   - Control: 1139; Revision: 3; Updated: Apr-15; Applicability: UD, P,
>C, S, TS; Compliance: should; Authority: AA
>   - Agencies *should use the latest version of TLS*
>
> Kind regards
>
> Paul Wilkins
>
> On 24 July 2018 at 11:10, Scott Howard  wrote:
>
>> On Mon, Jul 23, 2018 at 6:00 PM, Noel Butler 
>> wrote:
>>>
>>> You are the one choosing to use cpanel/plesk, lazy webhost solutions
>>> that
>>> puts all your customers eggs in the one single basket (though I heard
>>> plesk
>>> may soon be changing that), sorry, but that is not TPG's fault your
>>> chosen
>>> hosting software lives in the 90s.
>>>
>>
>> Perhaps not, but it IS TPG's fault that their mail server is only
>> supporting encryption algorithms that live in the 90's...
>>
>> Irrespective of the PCI argument or not, TPG supporting TLS 1.0 but not
>> higher in 2018 simply shouldn't be seen as acceptable.
>>
>>   Scott
>>
>>
>> ___
>> AusNOG mailing list
>> AusNOG@lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>>
> ___
> AusNOG mailing list
> AusNOG@lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>


___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Paul Wilkins]

Should TLS 1.0 be acceptable?

I don't claim to be a crypto geek.

Curiously the ISM standards make TLS 1.2 only advisory:


   - Control: 1447; Revision: 0; Updated: Apr-15; Applicability: UD, P, C,
   S, TS; Compliance: must; Authority: AA
  - Agencies *must use TLS*.
  -
  - Control: 1139; Revision: 3; Updated: Apr-15; Applicability: UD, P,
   C, S, TS; Compliance: should; Authority: AA
  - Agencies *should use the latest version of TLS*

Kind regards

Paul Wilkins

On 24 July 2018 at 11:10, Scott Howard  wrote:

> On Mon, Jul 23, 2018 at 6:00 PM, Noel Butler 
> wrote:
>>
>> You are the one choosing to use cpanel/plesk, lazy webhost solutions that
>> puts all your customers eggs in the one single basket (though I heard plesk
>> may soon be changing that), sorry, but that is not TPG's fault your chosen
>> hosting software lives in the 90s.
>>
>
> Perhaps not, but it IS TPG's fault that their mail server is only
> supporting encryption algorithms that live in the 90's...
>
> Irrespective of the PCI argument or not, TPG supporting TLS 1.0 but not
> higher in 2018 simply shouldn't be seen as acceptable.
>
>   Scott
>
>
> ___
> AusNOG mailing list
> AusNOG@lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Mal]

On 24/07/2018 6:54 AM, Mark Foster wrote:

>> Un-authenticated mail, however, doesn't require credentials in order to
>> accept mail, however, unless that server is relay, it also won't pass that
>> mail on. It would only accept mail from a server if the mailbox was
>> actually on it. So when a sending MTA sends mail to us, our server will
>> accept it if the email account is on that server.
>> This *doesn't* require authentication and thus no username or password are
>> supplied. As such encryption isn't required because there are no details
>> to
>> steal, unless as someone pointed out, you're silly enough to send credit
>> card details via email.
> 
> ... and if you are sending or receiving email from the world-at-large
> (thus, unauthenticated, as you put it) then you can't mandate encryption,
> true.

This is simply incorrect.  You can mandate encryption for transport
layer security with DANE.  This migrates opportunistic TLS into
mandatory, as required.

No usernames are required !  :)

Postfix (MTA) supports DANE and tls_policy maps can be configured to
ensure 'partner' domains are communicated via secure channel only.
Should the remote partner not have suitable TLSA records, the connection
will soft-fail until the remote end is corrected.  This guarantees that
an encrypted connection will be used, provided the remote party offers
StartTLS / DNSSEC / publishes TLSA records.

For other domains not associated with the PCI connection domain (the
remote partner you want to ensure encryption with), opportunistic TLS
applies, if supported by the remote end, per any normal email transmission.


Mal

___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Scott Howard]

On Mon, Jul 23, 2018 at 6:00 PM, Noel Butler  wrote:
>
> You are the one choosing to use cpanel/plesk, lazy webhost solutions that
> puts all your customers eggs in the one single basket (though I heard plesk
> may soon be changing that), sorry, but that is not TPG's fault your chosen
> hosting software lives in the 90s.
>

Perhaps not, but it IS TPG's fault that their mail server is only
supporting encryption algorithms that live in the 90's...

Irrespective of the PCI argument or not, TPG supporting TLS 1.0 but not
higher in 2018 simply shouldn't be seen as acceptable.

  Scott
___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Noel Butler]

On 23/07/2018 15:40, Bradley Silverman wrote:

> @Mark - These are shared hosting servers, think cPanel & Plesk. The one 
> server is both mail, and website. Which means that the server has websites 
> that accept credit card payments, and therefore is subject to PCI. Any system 
> that is on that server is required to comply with PCI.

  You are the one choosing to use cpanel/plesk, lazy webhost solutions
that puts all your customers eggs in the one single basket (though I
heard plesk may soon be changing that), sorry, but that is not TPG's
fault your chosen hosting software lives in the 90s. 

-- 
Kind Regards, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Paul Wilkins]

Granted there's likely environment/business/DNS specifics in Bradley's
environment, but there seems 2 clear requirements:

Exim mail on internal servers

Mail exchange (inc TLS1.0) with ISG.

You're not going to get there by making this ISG's problem.
1 - It's not their problem
2 - There's the rest of the internet where any inbound server may attempt
TLS1.0

Best way forward is likely SSL intercept on an external facing MTA, that
supports TLS1.0 front end, TLS1.2 to the Exim servers on the back end.

Kind regards

Paul Wilkins


On 24 July 2018 at 07:24, Mark Foster  wrote:

> > Hi Mark,
> >
> > Exim has two types of receiving:
> > Authenticated Mail
> > Un-authenticated mail.
>
> This I think we all understand.
>
> >
> > The difference is that when using the server for Authenticated mail, the
> > user must supply valid credentials in order to send mail through it. This
> > is what you would use for a mail client, such as Outlook. The connecting
> > server (unless it is an open relay) requires that you provide details in
> > order to send mail through it, and then that server will forward it on to
> > the next server.
> > If you do this, and that server is used for payments and the like, the
> > then
> > you must comply with PCI.
>
> If you control all external interactions the server has, then sure. That
> would then mean you need an external mail relay that you control
>
>
> > In a cPanel environment, where mail and hosting
> > are on the same server, this isn't optional if we wish to tell customers
> > that the servers there data is on is PCI compliant.
>
> >
> > Un-authenticated mail, however, doesn't require credentials in order to
> > accept mail, however, unless that server is relay, it also won't pass
> that
> > mail on. It would only accept mail from a server if the mailbox was
> > actually on it. So when a sending MTA sends mail to us, our server will
> > accept it if the email account is on that server.
> > This *doesn't* require authentication and thus no username or password
> are
> > supplied. As such encryption isn't required because there are no details
> > to
> > steal, unless as someone pointed out, you're silly enough to send credit
> > card details via email.
>
> ... and if you are sending or receiving email from the world-at-large
> (thus, unauthenticated, as you put it) then you can't mandate encryption,
> true.
>
>
> >
> > I appreciate everyone's help, and I do understand where you are all
> coming
> > from. But I assure you:
> > - Both mail and web hosting will almost always be on the same server in a
> > shared hosting environment.
> > - If the same server is both hosting websites that have credit card
> > details, and having a mail program such as Exim, then Exim must comply
> > with
> > PCI.
> > - If you do plan on having both on the same server, the server must
> comply
> > with the minimum highest spec to qualify (since there is web hosting that
> > requires high levels of encryption, the mail also requires it, where as
> if
> > the mail server was by itself you could use a lesser encryption.
>
> ... but this is where you lose it. You can't _require_ encryption if your
> MTA is talking to the public internet. It simply doesn't fly.
>
> I would be surprised if any shared/public hosting environment can also
> deliver PCI compliance as a result. Dedicated tin ensuring segregation
> between your systems and those of $RANDOM_STRANGER is required.
> Or have we forgotton meltdown/spectre?
>
> >
> > Please don't think I am not thankful for all your help, I just wanted to
> > make it clear what we've been told and what I understand from my own
> > research.
> >
> > You are all right that in a perfect world they would be on totally
> > seperate
> > servers, but for shared hosting this is almost always not going to be the
> > case!
>
>
> I don't see how you can be PCI compliant and also use shared hosting.
>
> Logically you could achieve in-the-clear support for external SMTP by
> having a dedicated smarthost outside of your PCI environment, that you
> also control of, thus you could control the support for encryption both
> sides. But you need to support non-compliant protocols for talking to the
> rest of the world, and expecting the rest of the world to conform to your
> expectations is unreasonable. Hell, even RFC compliance (the baseline,
> minimum just to be able to reliably communicate, nevermind encrypt) is
> iffy.
>
>
> Mark.
>
> ___
> AusNOG mailing list
> AusNOG@lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Mark Foster]

> Hi Mark,
>
> Exim has two types of receiving:
> Authenticated Mail
> Un-authenticated mail.

This I think we all understand.

>
> The difference is that when using the server for Authenticated mail, the
> user must supply valid credentials in order to send mail through it. This
> is what you would use for a mail client, such as Outlook. The connecting
> server (unless it is an open relay) requires that you provide details in
> order to send mail through it, and then that server will forward it on to
> the next server.
> If you do this, and that server is used for payments and the like, the
> then
> you must comply with PCI.

If you control all external interactions the server has, then sure. That
would then mean you need an external mail relay that you control


> In a cPanel environment, where mail and hosting
> are on the same server, this isn't optional if we wish to tell customers
> that the servers there data is on is PCI compliant.

>
> Un-authenticated mail, however, doesn't require credentials in order to
> accept mail, however, unless that server is relay, it also won't pass that
> mail on. It would only accept mail from a server if the mailbox was
> actually on it. So when a sending MTA sends mail to us, our server will
> accept it if the email account is on that server.
> This *doesn't* require authentication and thus no username or password are
> supplied. As such encryption isn't required because there are no details
> to
> steal, unless as someone pointed out, you're silly enough to send credit
> card details via email.

... and if you are sending or receiving email from the world-at-large
(thus, unauthenticated, as you put it) then you can't mandate encryption,
true.


>
> I appreciate everyone's help, and I do understand where you are all coming
> from. But I assure you:
> - Both mail and web hosting will almost always be on the same server in a
> shared hosting environment.
> - If the same server is both hosting websites that have credit card
> details, and having a mail program such as Exim, then Exim must comply
> with
> PCI.
> - If you do plan on having both on the same server, the server must comply
> with the minimum highest spec to qualify (since there is web hosting that
> requires high levels of encryption, the mail also requires it, where as if
> the mail server was by itself you could use a lesser encryption.

... but this is where you lose it. You can't _require_ encryption if your
MTA is talking to the public internet. It simply doesn't fly.

I would be surprised if any shared/public hosting environment can also
deliver PCI compliance as a result. Dedicated tin ensuring segregation
between your systems and those of $RANDOM_STRANGER is required.
Or have we forgotton meltdown/spectre?

>
> Please don't think I am not thankful for all your help, I just wanted to
> make it clear what we've been told and what I understand from my own
> research.
>
> You are all right that in a perfect world they would be on totally
> seperate
> servers, but for shared hosting this is almost always not going to be the
> case!


I don't see how you can be PCI compliant and also use shared hosting.

Logically you could achieve in-the-clear support for external SMTP by
having a dedicated smarthost outside of your PCI environment, that you
also control of, thus you could control the support for encryption both
sides. But you need to support non-compliant protocols for talking to the
rest of the world, and expecting the rest of the world to conform to your
expectations is unreasonable. Hell, even RFC compliance (the baseline,
minimum just to be able to reliably communicate, nevermind encrypt) is
iffy.


Mark.

___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Bradley Silverman]

Hi Mark,

Exim has two types of receiving:
Authenticated Mail
Un-authenticated mail.

The difference is that when using the server for Authenticated mail, the
user must supply valid credentials in order to send mail through it. This
is what you would use for a mail client, such as Outlook. The connecting
server (unless it is an open relay) requires that you provide details in
order to send mail through it, and then that server will forward it on to
the next server.
If you do this, and that server is used for payments and the like, the then
you must comply with PCI. In a cPanel environment, where mail and hosting
are on the same server, this isn't optional if we wish to tell customers
that the servers there data is on is PCI compliant.

Un-authenticated mail, however, doesn't require credentials in order to
accept mail, however, unless that server is relay, it also won't pass that
mail on. It would only accept mail from a server if the mailbox was
actually on it. So when a sending MTA sends mail to us, our server will
accept it if the email account is on that server.
This *doesn't* require authentication and thus no username or password are
supplied. As such encryption isn't required because there are no details to
steal, unless as someone pointed out, you're silly enough to send credit
card details via email.

I appreciate everyone's help, and I do understand where you are all coming
from. But I assure you:
- Both mail and web hosting will almost always be on the same server in a
shared hosting environment.
- If the same server is both hosting websites that have credit card
details, and having a mail program such as Exim, then Exim must comply with
PCI.
- If you do plan on having both on the same server, the server must comply
with the minimum highest spec to qualify (since there is web hosting that
requires high levels of encryption, the mail also requires it, where as if
the mail server was by itself you could use a lesser encryption.

Please don't think I am not thankful for all your help, I just wanted to
make it clear what we've been told and what I understand from my own
research.

You are all right that in a perfect world they would be on totally seperate
servers, but for shared hosting this is almost always not going to be the
case!

Thanks again guys!

Regards,

Bradley Silverman | VentraIP Australia
*Technical Operations*

mobile. +61 418 641 103
phone. +61 3 9013 8464

On Mon, Jul 23, 2018 at 7:34 PM, James Hodgkinson 
wrote:

> I think we all need to step back a bit, let OP do what his auditor feels
> is right, then thank him on behalf of EFF’s StartTLSEverywhere project...
> [1]
>
> ;)
>
> James
>
> [1] https://starttls-everywhere.org
>
>
> On Mon, 23 Jul 2018, at 18:21, Mark Foster wrote:
>
> Maybe i've missed something. Email is valid to shift around in plain text.
> TLS 1.0 might not be acceptable if you're talking minimum encryption
> standards, but I agree with the posters that point out that the Payment
> Card environment should have no dependencies on any email exchange with
> third parties.  This sounds to me like a box-ticking exercise where the
> right action on the public internet is to generally support the lowest
> common denominator unless it's insecure to do so - and in the case of
> email, you have to assume all transactions are insecure anyway unless you
> have end-to-end controls in place (which clearly you don't in this case if
> TPG is one end!)
>
> In the end you should be able to exchange email with TPG without any
> encryption at all and it shouldn't affect your compliance, surely?! As you
> can't be held responsible for a third party system and shouldn't be
> dependent on its status for your compliance as a result.
>
> Disclaimer: Have never tried to seek PCI compliance in any system i've
> operated.
>
> Mark.
>
> On 23/07/2018 7:03 PM, Paul Wilkins wrote:
>
> PCI spec is pretty clear you're to have separation (virtual/physical)
> between PCI and other environments.
>
> OTOH, TPG SLA's do not require TLS1.0+.
>
> Someone is going to have to sling for an external MTA.
>
> Kind regards
>
> Paul Wilkins
>
> On 23 July 2018 at 16:01, Michael Junek  wrote:
>
> Just being the 'mean security consultant'  - the security level of each
> system could easily be argued - email would be considered low security for
> compatibility (which technically means that TLS1.0/SSL3 etc is
> acceptable) ; whereas the web servers are considered high security handling
> CHD, which means that they should covered under the full encrypted spec. It
> would also mean if that was considered, that 2.2.1 would apply, and
> seperation of function would be required.
>
>
>
> --
>
> *From:* 

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Mal]

On 23/07/2018 7:04 PM, James Hodgkinson wrote:
> I think we all need to step back a bit, let OP do what his auditor feels
> is right, then thank him on behalf of EFF’s StartTLSEverywhere
> project... [1]
> ;)
> 
> James
> 
> [1] https://starttls-everywhere.org
> 

Whilst i agree with the early comments that SMTP might not be the best
exchange mechanism here for the actual payment card information, this
could be a solution using of a pair of MTAs configured with DANE TLSA
enforcement.

Using StartTLS with DNSSEC and DANE TLSA in place would likely have PCI
compliance, as you can guarantee the end-to-end hosts, and guarantee TLS
usage.  The participating MTAs would need to be configured for 'DANE
only' to ensure compliance.  Therefore, not part of any general email
infrastructure, as most domains lack DNSSEC signing in the first place,
let alone anything else.

Mal


___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[James Hodgkinson]

I think we all need to step back a bit, let OP do what his auditor feels
is right, then thank him on behalf of EFF’s StartTLSEverywhere
project... [1]
;)

James

[1] https://starttls-everywhere.org


On Mon, 23 Jul 2018, at 18:21, Mark Foster wrote:
> Maybe i've missed something. Email is valid to shift around in plain
> text. TLS 1.0 might not be acceptable if you're talking minimum
> encryption standards, but I agree with the posters that point out that
> the Payment Card environment should have no dependencies on any email
> exchange with third parties.  This sounds to me like a box-ticking
> exercise where the right action on the public internet is to generally
> support the lowest common denominator unless it's insecure to do so -
> and in the case of email, you have to assume all transactions are
> insecure anyway unless you have end-to-end controls in place (which
> clearly you don't in this case if TPG is one end!)> In the end you should be 
> able to exchange email with TPG without any
> encryption at all and it shouldn't affect your compliance, surely?! As
> you can't be held responsible for a third party system and shouldn't
> be dependent on its status for your compliance as a result.> Disclaimer: Have 
> never tried to seek PCI compliance in any system i've
> operated.> Mark.


> 
> On 23/07/2018 7:03 PM, Paul Wilkins wrote:
>> PCI spec is pretty clear you're to have separation (virtual/physical)
>> between PCI and other environments.>> 
>> OTOH, TPG SLA's do not require TLS1.0+.
>> 
>> Someone is going to have to sling for an external MTA.
>> 
>> Kind regards
>> 
>> Paul Wilkins
>> 
>> On 23 July 2018 at 16:01, Michael Junek
>>  wrote:>> 
>>> Just being the 'mean security consultant'  - the security level of
>>> each system could easily be argued - email would be considered low
>>> security for compatibility (which technically means that TLS1.0/SSL3
>>> etc is acceptable) ; whereas the web servers are considered high
>>> security handling CHD, which means that they should covered under
>>> the full encrypted spec. It would also mean if that was considered,
>>> that 2.2.1 would apply, and seperation of function would be
>>> required.>>> 


>>> 


>>> 
>>> *From:* Bradley Silverman  *Sent:*
>>> Monday, 23 July 2018 15:56 *To:* Michael Junek *Cc:* Mark Newton;
>>> ausnog@lists.ausnog.net>>>
>>> *Subject:* Re: [AusNOG] Issues receiving from TPG Mail servers.>>> 
>>>  
>>> @Michael - That's what we are looking at doing, though it will be a
>>> pain. Not sure how to go about doing it with Exim & cPanel but will
>>> start looking into it.>>> 
>>> Re 2.2.1, it won't fail if they have the same security level, which
>>> is what we are trying to accomplish by bringing TPG into spec. DNS
>>> is on separate servers, and the database connection isn't publicly
>>> accessible.>>> 
>>> Really appreciate the help with this gents. Hopefully TPG get back
>>> in touch with me else we will have to investigate ways of blocking
>>> TLS handshakes from TPG.>>> 
>>> Regards, 
>>> 
>>> Bradley Silverman | VentraIP Australia
>>> *Technical Operations*
>>> 
>>>  mobile. +61 418 641 103
>>>  phone. +61 3 9013 8464
>>> 
>>> On Mon, Jul 23, 2018 at 3:48 PM, Michael Junek
>>>  wrote:>>> 
>>>> On the PCI Audit side of things, however, I think the shared
>>>> hosting such as CPanel servers will fail PCI based on requirement
>>>> 2.2.1 regardless-->>>> 


>>>> "


>>>> Implement only one primary function per server to prevent functions
>>>> that require different security levels from co-existing on the same
>>>> server. (For example, web servers, database servers, and DNS should
>>>> be implemented on separate servers.)>>>> "


>>>> 


>>>> 


>>>> 


>>>> 


>>>> 
>>>> *From:* AusNOG  on behalf of
>>>> Bradley Silverman  *Sent:* Monday,
>>>> 23 July 2018 15:40 *To:* Mark Newton *Cc:* ausnog@lists.ausnog.net
>>>> *Subject:* Re: [AusNOG] Issues receiving from TPG Mail servers.>>>>  
>>>> 
>>>> @Michael - I agree that turning it off is the best way of solving
>>>> it, the issue is we don't have the servers forcing TLS, that's TPG.>>>

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Mark Foster]

Maybe i've missed something. Email is valid to shift around in plain 
text. TLS 1.0 might not be acceptable if you're talking minimum 
encryption standards, but I agree with the posters that point out that 
the Payment Card environment should have no dependencies on any email 
exchange with third parties.  This sounds to me like a box-ticking 
exercise where the right action on the public internet is to generally 
support the lowest common denominator unless it's insecure to do so - 
and in the case of email, you have to assume all transactions are 
insecure anyway unless you have end-to-end controls in place (which 
clearly you don't in this case if TPG is one end!)


In the end you should be able to exchange email with TPG without any 
encryption at all and it shouldn't affect your compliance, surely?! As 
you can't be held responsible for a third party system and shouldn't be 
dependent on its status for your compliance as a result.


Disclaimer: Have never tried to seek PCI compliance in any system i've 
operated.


Mark.


On 23/07/2018 7:03 PM, Paul Wilkins wrote:
PCI spec is pretty clear you're to have separation (virtual/physical) 
between PCI and other environments.


OTOH, TPG SLA's do not require TLS1.0+.

Someone is going to have to sling for an external MTA.

Kind regards

Paul Wilkins

On 23 July 2018 at 16:01, Michael Junek <mailto:mich...@juneks.com.au>> wrote:


Just being the 'mean security consultant'  - the security level of
each system could easily be argued - email would be considered low
security for compatibility (which technically means that
TLS1.0/SSL3 etc is acceptable) ; whereas the web servers are
considered high security handling CHD, which means that they
should covered under the full encrypted spec. It would also mean
if that was considered, that 2.2.1 would apply, and seperation of
function would be required.




*From:* Bradley Silverman mailto:bsilver...@staff.ventraip.com>>
*Sent:* Monday, 23 July 2018 15:56
*To:* Michael Junek
*Cc:* Mark Newton; ausnog@lists.ausnog.net
<mailto:ausnog@lists.ausnog.net>

*Subject:* Re: [AusNOG] Issues receiving from TPG Mail servers.
@Michael - That's what we are looking at doing, though it will be
a pain. Not sure how to go about doing it with Exim & cPanel but
will start looking into it.

Re 2.2.1, it won't fail if they have the same security level,
which is what we are trying to accomplish by bringing TPG into
spec. DNS is on separate servers, and the database connection
isn't publicly accessible.

Really appreciate the help with this gents. Hopefully TPG get back
in touch with me else we will have to investigate ways of blocking
TLS handshakes from TPG.

Regards,

Bradley Silverman | VentraIP Australia
*Technical Operations*

mobile. +61 418 641 103
phone. +61 3 9013 8464

On Mon, Jul 23, 2018 at 3:48 PM, Michael Junek
mailto:mich...@juneks.com.au>> wrote:

On the PCI Audit side of things, however, I think the shared
hosting such as CPanel servers will fail PCI based on
requirement 2.2.1 regardless--


"

Implement only one primary function per server to prevent
functions that require different security levels from
co-existing on the same server. (For example, web servers,
database servers, and DNS should be implemented on separate
servers.)

"






*From:* AusNOG mailto:ausnog-boun...@lists.ausnog.net>> on behalf of Bradley
Silverman mailto:bsilver...@staff.ventraip.com>>
*Sent:* Monday, 23 July 2018 15:40
    *To:* Mark Newton
    *Cc:* ausnog@lists.ausnog.net <mailto:ausnog@lists.ausnog.net>
*Subject:* Re: [AusNOG] Issues receiving from TPG Mail servers.
@Michael - I agree that turning it off is the best way of
solving it, the issue is we don't have the servers forcing
TLS, that's TPG.

@Mark - These are shared hosting servers, think cPanel &
Plesk. The one server is both mail, and website. Which means
that the server has websites that accept credit card payments,
and therefore is subject to PCI. Any system that is on that
server is required to comply with PCI.

If the server was website only, then I'd agree 100% that it
would be out of scope for PCI, but since the same server runs
both email and websites for shared hosting customers, it is in
scope.

We have zero issue with any other MTA, it is only these TPG
MTA's that are forcing both TLSv1.0 and an old cipher. If 

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Paul Wilkins]

PCI spec is pretty clear you're to have separation (virtual/physical)
between PCI and other environments.

OTOH, TPG SLA's do not require TLS1.0+.

Someone is going to have to sling for an external MTA.

Kind regards

Paul Wilkins

On 23 July 2018 at 16:01, Michael Junek  wrote:

> Just being the 'mean security consultant'  - the security level of each
> system could easily be argued - email would be considered low security for
> compatibility (which technically means that TLS1.0/SSL3 etc is
> acceptable) ; whereas the web servers are considered high security handling
> CHD, which means that they should covered under the full encrypted spec. It
> would also mean if that was considered, that 2.2.1 would apply, and
> seperation of function would be required.
>
>
>
> --
> *From:* Bradley Silverman 
> *Sent:* Monday, 23 July 2018 15:56
> *To:* Michael Junek
> *Cc:* Mark Newton; ausnog@lists.ausnog.net
>
> *Subject:* Re: [AusNOG] Issues receiving from TPG Mail servers.
>
> @Michael - That's what we are looking at doing, though it will be a pain.
> Not sure how to go about doing it with Exim & cPanel but will start looking
> into it.
>
> Re 2.2.1, it won't fail if they have the same security level, which is
> what we are trying to accomplish by bringing TPG into spec. DNS is on
> separate servers, and the database connection isn't publicly accessible.
>
> Really appreciate the help with this gents. Hopefully TPG get back in
> touch with me else we will have to investigate ways of blocking TLS
> handshakes from TPG.
>
> Regards,
>
> Bradley Silverman | VentraIP Australia
> *Technical Operations*
>
> mobile. +61 418 641 103
> phone. +61 3 9013 8464
>
> On Mon, Jul 23, 2018 at 3:48 PM, Michael Junek 
> wrote:
>
>> On the PCI Audit side of things, however, I think the shared hosting such
>> as CPanel servers will fail PCI based on requirement 2.2.1 regardless--
>>
>>
>> "
>>
>> Implement only one primary function per server to prevent functions that
>> require different security levels from co-existing on the same server. (For
>> example, web servers, database servers, and DNS should be implemented on
>> separate servers.)
>>
>> "
>>
>>
>>
>>
>>
>> --
>> *From:* AusNOG  on behalf of Bradley
>> Silverman 
>> *Sent:* Monday, 23 July 2018 15:40
>> *To:* Mark Newton
>> *Cc:* ausnog@lists.ausnog.net
>> *Subject:* Re: [AusNOG] Issues receiving from TPG Mail servers.
>>
>> @Michael - I agree that turning it off is the best way of solving it, the
>> issue is we don't have the servers forcing TLS, that's TPG.
>>
>> @Mark - These are shared hosting servers, think cPanel & Plesk. The one
>> server is both mail, and website. Which means that the server has websites
>> that accept credit card payments, and therefore is subject to PCI. Any
>> system that is on that server is required to comply with PCI.
>>
>> If the server was website only, then I'd agree 100% that it would be out
>> of scope for PCI, but since the same server runs both email and websites
>> for shared hosting customers, it is in scope.
>>
>> We have zero issue with any other MTA, it is only these TPG MTA's that
>> are forcing both TLSv1.0 and an old cipher. If they either turned off TLS
>> or upgraded to TLSv1.2 they would be up to spec.
>>
>> But we either have to make the decision to block TPG from being able to
>> send to the 100,000s of email accounts we have, or make it so that none of
>> our customers servers are PCI compliant. I'd rather speak to TPG and work
>> with them to fix the underlying problem.
>>
>> Regards,
>>
>> Bradley Silverman | VentraIP Australia
>> *Technical Operations*
>>
>> mobile. +61 418 641 103
>> phone. +61 3 9013 8464
>>
>> On Mon, Jul 23, 2018 at 3:34 PM, Mark Newton 
>> wrote:
>>
>>> But PCI Compliance only applies to the Cardholder Data Environment.
>>>
>>> Why on earth would you have a mail server in the Cardholder Data
>>> Environment?
>>>
>>> And if it isn’t in the CDE: You can run whatever version of TLS you
>>> want, and it’s none of PCI’s business.
>>>
>>>   - mark
>>>
>>>
>>>
>>> On Jul 23, 2018, at 3:06 PM, Bradley Silverman <
>>> bsilver...@staff.ventraip.com> wrote:
>>>
>>> Hi Matt,
>>>
>>> Really appreciate you sending me that email, I will definitely 

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Michael Junek]

Just being the 'mean security consultant'  - the security level of each system 
could easily be argued - email would be considered low security for 
compatibility (which technically means that TLS1.0/SSL3 etc is acceptable) ; 
whereas the web servers are considered high security handling CHD, which means 
that they should covered under the full encrypted spec. It would also mean if 
that was considered, that 2.2.1 would apply, and seperation of function would 
be required.




From: Bradley Silverman 
Sent: Monday, 23 July 2018 15:56
To: Michael Junek
Cc: Mark Newton; ausnog@lists.ausnog.net
Subject: Re: [AusNOG] Issues receiving from TPG Mail servers.

@Michael - That's what we are looking at doing, though it will be a pain. Not 
sure how to go about doing it with Exim & cPanel but will start looking into it.

Re 2.2.1, it won't fail if they have the same security level, which is what we 
are trying to accomplish by bringing TPG into spec. DNS is on separate servers, 
and the database connection isn't publicly accessible.

Really appreciate the help with this gents. Hopefully TPG get back in touch 
with me else we will have to investigate ways of blocking TLS handshakes from 
TPG.

Regards,

Bradley Silverman | VentraIP Australia
Technical Operations

mobile. +61 418 641 103
phone. +61 3 9013 8464

On Mon, Jul 23, 2018 at 3:48 PM, Michael Junek 
mailto:mich...@juneks.com.au>> wrote:

On the PCI Audit side of things, however, I think the shared hosting such as 
CPanel servers will fail PCI based on requirement 2.2.1 regardless--


"

Implement only one primary function per server to prevent functions that 
require different security levels from co-existing on the same server. (For 
example, web servers, database servers, and DNS should be implemented on 
separate servers.)

"






From: AusNOG 
mailto:ausnog-boun...@lists.ausnog.net>> on 
behalf of Bradley Silverman 
mailto:bsilver...@staff.ventraip.com>>
Sent: Monday, 23 July 2018 15:40
To: Mark Newton
Cc: ausnog@lists.ausnog.net<mailto:ausnog@lists.ausnog.net>
Subject: Re: [AusNOG] Issues receiving from TPG Mail servers.

@Michael - I agree that turning it off is the best way of solving it, the issue 
is we don't have the servers forcing TLS, that's TPG.

@Mark - These are shared hosting servers, think cPanel & Plesk. The one server 
is both mail, and website. Which means that the server has websites that accept 
credit card payments, and therefore is subject to PCI. Any system that is on 
that server is required to comply with PCI.

If the server was website only, then I'd agree 100% that it would be out of 
scope for PCI, but since the same server runs both email and websites for 
shared hosting customers, it is in scope.

We have zero issue with any other MTA, it is only these TPG MTA's that are 
forcing both TLSv1.0 and an old cipher. If they either turned off TLS or 
upgraded to TLSv1.2 they would be up to spec.

But we either have to make the decision to block TPG from being able to send to 
the 100,000s of email accounts we have, or make it so that none of our 
customers servers are PCI compliant. I'd rather speak to TPG and work with them 
to fix the underlying problem.

Regards,

Bradley Silverman | VentraIP Australia
Technical Operations

mobile. +61 418 641 103
phone. +61 3 9013 8464

On Mon, Jul 23, 2018 at 3:34 PM, Mark Newton 
mailto:new...@atdot.dotat.org>> wrote:
But PCI Compliance only applies to the Cardholder Data Environment.

Why on earth would you have a mail server in the Cardholder Data Environment?

And if it isn’t in the CDE: You can run whatever version of TLS you want, and 
it’s none of PCI’s business.

  - mark



On Jul 23, 2018, at 3:06 PM, Bradley Silverman 
mailto:bsilver...@staff.ventraip.com>> wrote:

Hi Matt,

Really appreciate you sending me that email, I will definitely send an email 
through to there!

@Mark Certainly not! PCI Compliance requires that TLSv1.0 be disabled on the 
server. Postifx/Exim/Dovecot are not exception to the rule, if we disable 
TLSv1.0 on the server and remove the weak cipher, then TPG's MTAs aren't able 
to send mail to us.

Regards,

Bradley Silverman | VentraIP Australia
Technical Operations

mobile. +61 418 641 103
phone. +61 3 9013 8464

On Mon, Jul 23, 2018 at 2:48 PM, Mark Newton 
mailto:new...@atdot.dotat.org>> wrote:
You’re trying to exchange payment card information over email?

  - mark

On Jul 23, 2018, at 1:30 PM, Bradley Silverman 
mailto:bsilver...@staff.ventraip.com>> wrote:

Does anyone have a contact at TPG regarding their mail servers?

We are having issues with their mail servers using non-PCI compliant ciphers 
which is stopping our servers accepting mail from them.


Regards,

Bradley Silverman | VentraIP Australia
Technical Operations

mobile. +61 418 641 103
phone. +61 3 9013 8

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Bradley Silverman]

@Michael - That's what we are looking at doing, though it will be a pain.
Not sure how to go about doing it with Exim & cPanel but will start looking
into it.

Re 2.2.1, it won't fail if they have the same security level, which is what
we are trying to accomplish by bringing TPG into spec. DNS is on separate
servers, and the database connection isn't publicly accessible.

Really appreciate the help with this gents. Hopefully TPG get back in touch
with me else we will have to investigate ways of blocking TLS handshakes
from TPG.

Regards,

Bradley Silverman | VentraIP Australia
*Technical Operations*

mobile. +61 418 641 103
phone. +61 3 9013 8464

On Mon, Jul 23, 2018 at 3:48 PM, Michael Junek 
wrote:

> On the PCI Audit side of things, however, I think the shared hosting such
> as CPanel servers will fail PCI based on requirement 2.2.1 regardless--
>
>
> "
>
> Implement only one primary function per server to prevent functions that
> require different security levels from co-existing on the same server. (For
> example, web servers, database servers, and DNS should be implemented on
> separate servers.)
>
> "
>
>
>
>
>
> --
> *From:* AusNOG  on behalf of Bradley
> Silverman 
> *Sent:* Monday, 23 July 2018 15:40
> *To:* Mark Newton
> *Cc:* ausnog@lists.ausnog.net
> *Subject:* Re: [AusNOG] Issues receiving from TPG Mail servers.
>
> @Michael - I agree that turning it off is the best way of solving it, the
> issue is we don't have the servers forcing TLS, that's TPG.
>
> @Mark - These are shared hosting servers, think cPanel & Plesk. The one
> server is both mail, and website. Which means that the server has websites
> that accept credit card payments, and therefore is subject to PCI. Any
> system that is on that server is required to comply with PCI.
>
> If the server was website only, then I'd agree 100% that it would be out
> of scope for PCI, but since the same server runs both email and websites
> for shared hosting customers, it is in scope.
>
> We have zero issue with any other MTA, it is only these TPG MTA's that are
> forcing both TLSv1.0 and an old cipher. If they either turned off TLS or
> upgraded to TLSv1.2 they would be up to spec.
>
> But we either have to make the decision to block TPG from being able to
> send to the 100,000s of email accounts we have, or make it so that none of
> our customers servers are PCI compliant. I'd rather speak to TPG and work
> with them to fix the underlying problem.
>
> Regards,
>
> Bradley Silverman | VentraIP Australia
> *Technical Operations*
>
> mobile. +61 418 641 103
> phone. +61 3 9013 8464
>
> On Mon, Jul 23, 2018 at 3:34 PM, Mark Newton 
> wrote:
>
>> But PCI Compliance only applies to the Cardholder Data Environment.
>>
>> Why on earth would you have a mail server in the Cardholder Data
>> Environment?
>>
>> And if it isn’t in the CDE: You can run whatever version of TLS you want,
>> and it’s none of PCI’s business.
>>
>>   - mark
>>
>>
>>
>> On Jul 23, 2018, at 3:06 PM, Bradley Silverman <
>> bsilver...@staff.ventraip.com> wrote:
>>
>> Hi Matt,
>>
>> Really appreciate you sending me that email, I will definitely send an
>> email through to there!
>>
>> @Mark Certainly not! PCI Compliance requires that TLSv1.0 be disabled on
>> the server. Postifx/Exim/Dovecot are not exception to the rule, if we
>> disable TLSv1.0 on the server and remove the weak cipher, then TPG's MTAs
>> aren't able to send mail to us.
>>
>> Regards,
>>
>> Bradley Silverman | VentraIP Australia
>> *Technical Operations*
>>
>> mobile. +61 418 641 103
>> phone. +61 3 9013 8464
>>
>> On Mon, Jul 23, 2018 at 2:48 PM, Mark Newton 
>> wrote:
>>
>>> You’re trying to exchange payment card information over email?
>>>
>>>   - mark
>>>
>>> On Jul 23, 2018, at 1:30 PM, Bradley Silverman <
>>> bsilver...@staff.ventraip.com> wrote:
>>>
>>> Does anyone have a contact at TPG regarding their mail servers?
>>>
>>> We are having issues with their mail servers using non-PCI compliant
>>> ciphers which is stopping our servers accepting mail from them.
>>>
>>>
>>> Regards,
>>>
>>> Bradley Silverman | VentraIP Australia
>>> *Technical Operations*
>>>
>>> mobile. +61 418 641 103
>>> phone. +61 3 9013 8464
>>> ___
>>> AusNOG mailing list
>>> AusNOG@lists.ausnog.net
>>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>>
>>>
>>>
>>
>>
>
___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Michael Junek]

On the PCI Audit side of things, however, I think the shared hosting such as 
CPanel servers will fail PCI based on requirement 2.2.1 regardless--


"

Implement only one primary function per server to prevent functions that 
require different security levels from co-existing on the same server. (For 
example, web servers, database servers, and DNS should be implemented on 
separate servers.)

"






From: AusNOG  on behalf of Bradley Silverman 

Sent: Monday, 23 July 2018 15:40
To: Mark Newton
Cc: ausnog@lists.ausnog.net
Subject: Re: [AusNOG] Issues receiving from TPG Mail servers.

@Michael - I agree that turning it off is the best way of solving it, the issue 
is we don't have the servers forcing TLS, that's TPG.

@Mark - These are shared hosting servers, think cPanel & Plesk. The one server 
is both mail, and website. Which means that the server has websites that accept 
credit card payments, and therefore is subject to PCI. Any system that is on 
that server is required to comply with PCI.

If the server was website only, then I'd agree 100% that it would be out of 
scope for PCI, but since the same server runs both email and websites for 
shared hosting customers, it is in scope.

We have zero issue with any other MTA, it is only these TPG MTA's that are 
forcing both TLSv1.0 and an old cipher. If they either turned off TLS or 
upgraded to TLSv1.2 they would be up to spec.

But we either have to make the decision to block TPG from being able to send to 
the 100,000s of email accounts we have, or make it so that none of our 
customers servers are PCI compliant. I'd rather speak to TPG and work with them 
to fix the underlying problem.

Regards,

Bradley Silverman | VentraIP Australia
Technical Operations

mobile. +61 418 641 103
phone. +61 3 9013 8464

On Mon, Jul 23, 2018 at 3:34 PM, Mark Newton 
mailto:new...@atdot.dotat.org>> wrote:
But PCI Compliance only applies to the Cardholder Data Environment.

Why on earth would you have a mail server in the Cardholder Data Environment?

And if it isn't in the CDE: You can run whatever version of TLS you want, and 
it's none of PCI's business.

  - mark



On Jul 23, 2018, at 3:06 PM, Bradley Silverman 
mailto:bsilver...@staff.ventraip.com>> wrote:

Hi Matt,

Really appreciate you sending me that email, I will definitely send an email 
through to there!

@Mark Certainly not! PCI Compliance requires that TLSv1.0 be disabled on the 
server. Postifx/Exim/Dovecot are not exception to the rule, if we disable 
TLSv1.0 on the server and remove the weak cipher, then TPG's MTAs aren't able 
to send mail to us.

Regards,

Bradley Silverman | VentraIP Australia
Technical Operations

mobile. +61 418 641 103
phone. +61 3 9013 8464

On Mon, Jul 23, 2018 at 2:48 PM, Mark Newton 
mailto:new...@atdot.dotat.org>> wrote:
You're trying to exchange payment card information over email?

  - mark

On Jul 23, 2018, at 1:30 PM, Bradley Silverman 
mailto:bsilver...@staff.ventraip.com>> wrote:

Does anyone have a contact at TPG regarding their mail servers?

We are having issues with their mail servers using non-PCI compliant ciphers 
which is stopping our servers accepting mail from them.


Regards,

Bradley Silverman | VentraIP Australia
Technical Operations

mobile. +61 418 641 103
phone. +61 3 9013 8464
___
AusNOG mailing list
AusNOG@lists.ausnog.net<mailto:AusNOG@lists.ausnog.net>
http://lists.ausnog.net/mailman/listinfo/ausnog




___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Michael Junek]

Addressing the issue at hand, can you set your MTA not to offer STARTTLS 
command in the EHLO towards the TPG IP addresses, to force them to use the 
unencrypted channel?


Surely others who have played with their TLS1.2 settings on their MTA's are 
having this issue as well with TPG; how would they have gotten around it?


M.





From: AusNOG  on behalf of Bradley Silverman 

Sent: Monday, 23 July 2018 15:40
To: Mark Newton
Cc: ausnog@lists.ausnog.net
Subject: Re: [AusNOG] Issues receiving from TPG Mail servers.

@Michael - I agree that turning it off is the best way of solving it, the issue 
is we don't have the servers forcing TLS, that's TPG.

@Mark - These are shared hosting servers, think cPanel & Plesk. The one server 
is both mail, and website. Which means that the server has websites that accept 
credit card payments, and therefore is subject to PCI. Any system that is on 
that server is required to comply with PCI.

If the server was website only, then I'd agree 100% that it would be out of 
scope for PCI, but since the same server runs both email and websites for 
shared hosting customers, it is in scope.

We have zero issue with any other MTA, it is only these TPG MTA's that are 
forcing both TLSv1.0 and an old cipher. If they either turned off TLS or 
upgraded to TLSv1.2 they would be up to spec.

But we either have to make the decision to block TPG from being able to send to 
the 100,000s of email accounts we have, or make it so that none of our 
customers servers are PCI compliant. I'd rather speak to TPG and work with them 
to fix the underlying problem.

Regards,

Bradley Silverman | VentraIP Australia
Technical Operations

mobile. +61 418 641 103
phone. +61 3 9013 8464

On Mon, Jul 23, 2018 at 3:34 PM, Mark Newton 
mailto:new...@atdot.dotat.org>> wrote:
But PCI Compliance only applies to the Cardholder Data Environment.

Why on earth would you have a mail server in the Cardholder Data Environment?

And if it isn't in the CDE: You can run whatever version of TLS you want, and 
it's none of PCI's business.

  - mark



On Jul 23, 2018, at 3:06 PM, Bradley Silverman 
mailto:bsilver...@staff.ventraip.com>> wrote:

Hi Matt,

Really appreciate you sending me that email, I will definitely send an email 
through to there!

@Mark Certainly not! PCI Compliance requires that TLSv1.0 be disabled on the 
server. Postifx/Exim/Dovecot are not exception to the rule, if we disable 
TLSv1.0 on the server and remove the weak cipher, then TPG's MTAs aren't able 
to send mail to us.

Regards,

Bradley Silverman | VentraIP Australia
Technical Operations

mobile. +61 418 641 103
phone. +61 3 9013 8464

On Mon, Jul 23, 2018 at 2:48 PM, Mark Newton 
mailto:new...@atdot.dotat.org>> wrote:
You're trying to exchange payment card information over email?

  - mark

On Jul 23, 2018, at 1:30 PM, Bradley Silverman 
mailto:bsilver...@staff.ventraip.com>> wrote:

Does anyone have a contact at TPG regarding their mail servers?

We are having issues with their mail servers using non-PCI compliant ciphers 
which is stopping our servers accepting mail from them.


Regards,

Bradley Silverman | VentraIP Australia
Technical Operations

mobile. +61 418 641 103
phone. +61 3 9013 8464
___
AusNOG mailing list
AusNOG@lists.ausnog.net<mailto:AusNOG@lists.ausnog.net>
http://lists.ausnog.net/mailman/listinfo/ausnog




___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Bradley Silverman]

@Michael - I agree that turning it off is the best way of solving it, the
issue is we don't have the servers forcing TLS, that's TPG.

@Mark - These are shared hosting servers, think cPanel & Plesk. The one
server is both mail, and website. Which means that the server has websites
that accept credit card payments, and therefore is subject to PCI. Any
system that is on that server is required to comply with PCI.

If the server was website only, then I'd agree 100% that it would be out of
scope for PCI, but since the same server runs both email and websites for
shared hosting customers, it is in scope.

We have zero issue with any other MTA, it is only these TPG MTA's that are
forcing both TLSv1.0 and an old cipher. If they either turned off TLS or
upgraded to TLSv1.2 they would be up to spec.

But we either have to make the decision to block TPG from being able to
send to the 100,000s of email accounts we have, or make it so that none of
our customers servers are PCI compliant. I'd rather speak to TPG and work
with them to fix the underlying problem.

Regards,

Bradley Silverman | VentraIP Australia
*Technical Operations*

mobile. +61 418 641 103
phone. +61 3 9013 8464

On Mon, Jul 23, 2018 at 3:34 PM, Mark Newton  wrote:

> But PCI Compliance only applies to the Cardholder Data Environment.
>
> Why on earth would you have a mail server in the Cardholder Data
> Environment?
>
> And if it isn’t in the CDE: You can run whatever version of TLS you want,
> and it’s none of PCI’s business.
>
>   - mark
>
>
>
> On Jul 23, 2018, at 3:06 PM, Bradley Silverman <
> bsilver...@staff.ventraip.com> wrote:
>
> Hi Matt,
>
> Really appreciate you sending me that email, I will definitely send an
> email through to there!
>
> @Mark Certainly not! PCI Compliance requires that TLSv1.0 be disabled on
> the server. Postifx/Exim/Dovecot are not exception to the rule, if we
> disable TLSv1.0 on the server and remove the weak cipher, then TPG's MTAs
> aren't able to send mail to us.
>
> Regards,
>
> Bradley Silverman | VentraIP Australia
> *Technical Operations*
>
> mobile. +61 418 641 103
> phone. +61 3 9013 8464
>
> On Mon, Jul 23, 2018 at 2:48 PM, Mark Newton 
> wrote:
>
>> You’re trying to exchange payment card information over email?
>>
>>   - mark
>>
>> On Jul 23, 2018, at 1:30 PM, Bradley Silverman <
>> bsilver...@staff.ventraip.com> wrote:
>>
>> Does anyone have a contact at TPG regarding their mail servers?
>>
>> We are having issues with their mail servers using non-PCI compliant
>> ciphers which is stopping our servers accepting mail from them.
>>
>>
>> Regards,
>>
>> Bradley Silverman | VentraIP Australia
>> *Technical Operations*
>>
>> mobile. +61 418 641 103
>> phone. +61 3 9013 8464
>> ___
>> AusNOG mailing list
>> AusNOG@lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>>
>>
>
>
___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Mark Newton]

> On Jul 23, 2018, at 3:27 PM, Rob Thomas  wrote:
> 
>> But shouldn't your public mail server be out of scope for PCI?
> 
> Here. ladies and gentleman, is a nerd that has never encountered the
> insanity and conflicting information that is PCI.  Be quiet, we don't
> want to scare it.
> 
> In all seriousness, yes, they will fail you if you have anything
> listening on a machine that accepts TLS1.0 connections.

Then you push back, and they don’t.

That’s how it works.

If you have an incompetent auditor and you’re a passive customer, you’re going 
to have a bad time.

If you know what you’re doing, know where the boundaries of the CDE are, and 
know what the PCI-DSS spec actually says, and push back on the auditor’s 
nonsense when they step out of bounds, then you’ll have a better time.

You’re the auditor’s customer. You have a right to expect that they aren’t shit.

  - mark



___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Mark Newton]

But PCI Compliance only applies to the Cardholder Data Environment.

Why on earth would you have a mail server in the Cardholder Data Environment?

And if it isn’t in the CDE: You can run whatever version of TLS you want, and 
it’s none of PCI’s business.

  - mark



> On Jul 23, 2018, at 3:06 PM, Bradley Silverman 
>  wrote:
> 
> Hi Matt,
> 
> Really appreciate you sending me that email, I will definitely send an email 
> through to there!
> 
> @Mark Certainly not! PCI Compliance requires that TLSv1.0 be disabled on the 
> server. Postifx/Exim/Dovecot are not exception to the rule, if we disable 
> TLSv1.0 on the server and remove the weak cipher, then TPG's MTAs aren't able 
> to send mail to us.
> 
> Regards,
> 
> Bradley Silverman | VentraIP Australia
> Technical Operations
> 
> mobile. +61 418 641 103
> phone. +61 3 9013 8464
> 
> On Mon, Jul 23, 2018 at 2:48 PM, Mark Newton  > wrote:
> You’re trying to exchange payment card information over email?
> 
>   - mark
> 
>> On Jul 23, 2018, at 1:30 PM, Bradley Silverman 
>> mailto:bsilver...@staff.ventraip.com>> wrote:
>> 
>> Does anyone have a contact at TPG regarding their mail servers?
>> 
>> We are having issues with their mail servers using non-PCI compliant ciphers 
>> which is stopping our servers accepting mail from them.
>> 
>> 
>> Regards,
>> 
>> Bradley Silverman | VentraIP Australia
>> Technical Operations
>> 
>> mobile. +61 418 641 103
>> phone. +61 3 9013 8464
>> ___
>> AusNOG mailing list
>> AusNOG@lists.ausnog.net 
>> http://lists.ausnog.net/mailman/listinfo/ausnog 
>> 
> 
> 

___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Michael Junek]

Actually going through the pain of it all right now.
Fortunately our QSA is a little pragmatic about these things and isn't one of 
those checklisty type people - and would certainly offer suggestions about it, 
especially if there is a documented business reason why something cannot be 
enacted.

The easiest way around it is to disable TLS completely on your mail server. 
Won't fail PCI then. And everyone will send to you unencrypted. Doesn't fix the 
security issue, but it certainly fixes the mailflow.





From: Rob Thomas 
Sent: Monday, 23 July 2018 15:27
To: Michael Junek
Cc: Bradley Silverman; Mark Newton; ausnog@lists.ausnog.net
Subject: Re: [AusNOG] Issues receiving from TPG Mail servers.

> But shouldn't your public mail server be out of scope for PCI?

Here. ladies and gentleman, is a nerd that has never encountered the
insanity and conflicting information that is PCI.  Be quiet, we don't
want to scare it.

In all seriousness, yes, they will fail you if you have anything
listening on a machine that accepts TLS1.0 connections.  Or maybe they
won't. You don't know until you pay the $5k for the audit. And if they
DO fail you, you have to fix it. So I'm guessing that is where Bradley
is now. His PCI auditors have said 'No TLS1.0 on this server', and
that's the end of the discussion.

You don't get to reason with these people. They are accountants that
run scripts and have a checklist.  Common sense does not enter into
the equation.

--Rob
___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Bradley Silverman]

It's sort of makes sense that they won't allow it.

Users, regardless of best case, rarely have that many passwords, they
generally reuse the same one.

If you allow weak encryption on your SMTP then when connections are made
the password can be stolen and then often that password can be used to
access other things.

As this is a shared hosting environment it's quite possible that a customer
has the same password for email and cPanel or their website, and that's why
it's part of PCI.

>From what I know of PCI, anything on that server, that is accessible
publicly, needs to be up to spec.

Regards,

Bradley Silverman | VentraIP Australia
*Technical Operations*

mobile. +61 418 641 103
phone. +61 3 9013 8464

On Mon, Jul 23, 2018 at 3:27 PM, Rob Thomas  wrote:

> > But shouldn't your public mail server be out of scope for PCI?
>
> Here. ladies and gentleman, is a nerd that has never encountered the
> insanity and conflicting information that is PCI.  Be quiet, we don't
> want to scare it.
>
> In all seriousness, yes, they will fail you if you have anything
> listening on a machine that accepts TLS1.0 connections.  Or maybe they
> won't. You don't know until you pay the $5k for the audit. And if they
> DO fail you, you have to fix it. So I'm guessing that is where Bradley
> is now. His PCI auditors have said 'No TLS1.0 on this server', and
> that's the end of the discussion.
>
> You don't get to reason with these people. They are accountants that
> run scripts and have a checklist.  Common sense does not enter into
> the equation.
>
> --Rob
>
___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Rob Thomas]

> But shouldn't your public mail server be out of scope for PCI?

Here. ladies and gentleman, is a nerd that has never encountered the
insanity and conflicting information that is PCI.  Be quiet, we don't
want to scare it.

In all seriousness, yes, they will fail you if you have anything
listening on a machine that accepts TLS1.0 connections.  Or maybe they
won't. You don't know until you pay the $5k for the audit. And if they
DO fail you, you have to fix it. So I'm guessing that is where Bradley
is now. His PCI auditors have said 'No TLS1.0 on this server', and
that's the end of the discussion.

You don't get to reason with these people. They are accountants that
run scripts and have a checklist.  Common sense does not enter into
the equation.

--Rob
___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Michael Junek]

Given plenty of mail communication is still non-encrypted, having TLS1.0 is an 
improvement, granted 1.2 is the ultimate goal.

But shouldn't your public mail server be out of scope for PCI?

Surely it's not handling cardholder data, nor talking to a system that is, 
therefore should be excluded from the requirement?







From: AusNOG  on behalf of Bradley Silverman 

Sent: Monday, 23 July 2018 15:06
To: Mark Newton
Cc: ausnog@lists.ausnog.net
Subject: Re: [AusNOG] Issues receiving from TPG Mail servers.

Hi Matt,

Really appreciate you sending me that email, I will definitely send an email 
through to there!

@Mark Certainly not! PCI Compliance requires that TLSv1.0 be disabled on the 
server. Postifx/Exim/Dovecot are not exception to the rule, if we disable 
TLSv1.0 on the server and remove the weak cipher, then TPG's MTAs aren't able 
to send mail to us.

Regards,

Bradley Silverman | VentraIP Australia
Technical Operations

mobile. +61 418 641 103
phone. +61 3 9013 8464

On Mon, Jul 23, 2018 at 2:48 PM, Mark Newton 
mailto:new...@atdot.dotat.org>> wrote:
You're trying to exchange payment card information over email?

  - mark

On Jul 23, 2018, at 1:30 PM, Bradley Silverman 
mailto:bsilver...@staff.ventraip.com>> wrote:

Does anyone have a contact at TPG regarding their mail servers?

We are having issues with their mail servers using non-PCI compliant ciphers 
which is stopping our servers accepting mail from them.


Regards,

Bradley Silverman | VentraIP Australia
Technical Operations

mobile. +61 418 641 103
phone. +61 3 9013 8464
___
AusNOG mailing list
AusNOG@lists.ausnog.net<mailto:AusNOG@lists.ausnog.net>
http://lists.ausnog.net/mailman/listinfo/ausnog


___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Bradley Silverman]

Hi Matt,

Really appreciate you sending me that email, I will definitely send an
email through to there!

@Mark Certainly not! PCI Compliance requires that TLSv1.0 be disabled on
the server. Postifx/Exim/Dovecot are not exception to the rule, if we
disable TLSv1.0 on the server and remove the weak cipher, then TPG's MTAs
aren't able to send mail to us.

Regards,

Bradley Silverman | VentraIP Australia
*Technical Operations*

mobile. +61 418 641 103
phone. +61 3 9013 8464

On Mon, Jul 23, 2018 at 2:48 PM, Mark Newton  wrote:

> You’re trying to exchange payment card information over email?
>
>   - mark
>
> On Jul 23, 2018, at 1:30 PM, Bradley Silverman <
> bsilver...@staff.ventraip.com> wrote:
>
> Does anyone have a contact at TPG regarding their mail servers?
>
> We are having issues with their mail servers using non-PCI compliant
> ciphers which is stopping our servers accepting mail from them.
>
>
> Regards,
>
> Bradley Silverman | VentraIP Australia
> *Technical Operations*
>
> mobile. +61 418 641 103
> phone. +61 3 9013 8464
> ___
> AusNOG mailing list
> AusNOG@lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
>
___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

Re: [AusNOG] Issues receiving from TPG Mail servers.

[Mark Newton]

You’re trying to exchange payment card information over email?

  - mark

> On Jul 23, 2018, at 1:30 PM, Bradley Silverman 
>  wrote:
> 
> Does anyone have a contact at TPG regarding their mail servers?
> 
> We are having issues with their mail servers using non-PCI compliant ciphers 
> which is stopping our servers accepting mail from them.
> 
> 
> Regards,
> 
> Bradley Silverman | VentraIP Australia
> Technical Operations
> 
> mobile. +61 418 641 103
> phone. +61 3 9013 8464
> ___
> AusNOG mailing list
> AusNOG@lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog

___
AusNOG mailing list
AusNOG@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog