STARTTLS feedback?

Post by **martin** » 2014-08-30 15:48

myname wrote:So you think that if the recipient mailserver certificate is untrusted to not encrypt the transmission is better?

No I don't. Are you seeing this behavior with hMailServer or why do you think this is how it works?
Have you read the documentation about how it's supposed to work?

myname wrote:If I try send PM "You cannot send private messages before you've made 5 posts in the user forum."

Feel free to send it to me at martin at hmailserver.com. Or just make 3 dummy posts in "off topic" section.

You do realize that this is still a beta an open for feedback. No reason to get emotional and "sad" about the behavior. I recommend giving constructive feedback instead based on the documentation and the result you are seeing, because feeling "sad" will get you nowhere.

joseasl · Post by **joseasl** » 2014-08-31 15:32

Hi,
I noticed a big one where STARTTLS is not working. Delivering to Hotmail servers the connection is not secured, but it is to Gmail servers.
Is this known? Can it be a configuration problem or is it a bug?

Regards

mattg · Post by **mattg** » 2014-08-31 15:45

Is this general delivery, or from a Route?

Can you show some logs please?

joseasl · Post by **joseasl** » 2014-08-31 17:10

General delivery. I have to leave now. I'll post some logs later.

Regards

Post by **martin** » 2014-08-31 18:35

That's because Outlook does not advertise ESMTP support in the banner message. I will remove the requirement that the remote server must advertise support and just attempt to use it.

joseasl · Post by **joseasl** » 2014-08-31 20:57

Great!

Thanks for your work, Martin

Regards

percepts · Post by **percepts** » 2014-09-01 16:58

Martin,

Just wondering, have you included the fix that Bill made for the IOCP race condition into latest development build?

joseasl · Post by **joseasl** » 2014-09-01 17:50

percepts wrote:Martin,

Just wondering, have you included the fix that Bill made for the IOCP race condition into latest development build?

I was about to report a bug I saw today (Build 2058):

"ERROR" 3436 "2014-09-01 12:06:05.808" "Severity: 2 (High), Code: HM4208, Source: IOCPQueueWorkerTask::DoWork, Description: An unknown error occured while handling asynchronous requests."

As a result, the IMAP clients stopped working until I restarted the windows service (SMTP was working and receiving according to the logs).

Is the same error you refer?

Regards

percepts · Post by **percepts** » 2014-09-01 18:12

I can't say because I don't know exactly what the error was, only that it happened to some people and not to others and it could just suddenly start happening.

It was the one at following topic

viewtopic.php?f=10&t=21420

search for

2014-01-15 TEST-15Jan14-ALPHA

there were various attempted fixes prior to that but Bill found something during some STARTTLS testing that he thought may have been the cause of a race condition resulting in IOCP errors (maybe, its all a bit wooly to me)

Post by **martin** » 2014-09-04 19:28

The issue with the fix (which was not originally written by Bill but by another guy who submitted the patch to Bill) was that the root cause was not actually found. A 'lock' was added to a specific function but it was not clear why that solved the issue. I've now made a similar fix to the same function which I think should address that issue.

Post by **martin** » 2014-09-04 19:28

New beta is up btw, solving the issue with STARTTLS not being used with Hotmail and a few other things.

percepts · Post by **percepts** » 2014-09-04 19:47

OK, Thanks,

Will check it out in due course

Bill48105 · Post by **Bill48105** » 2014-09-06 20:53

martin wrote:The issue with the fix (which was not originally written by Bill but by another guy who submitted the patch to Bill) was that the root cause was not actually found. A 'lock' was added to a specific function but it was not clear why that solved the issue. I've now made a similar fix to the same function which I think should address that issue.

FYI there have been multiple changes called IOCP fixes. Indeed the one you refer to was submitted by someone else & it didn't seem to make any difference but was left as it didn't seem to break anything either. If you recall I asked you to look at it for input on what effect positive or negative it might have but you never responded.

The later IOCP fixes percepts mentioned were indeed found during the STARTTLS testing as the crashes happened almost non-stop. Those changes made at that time are the ones that appear to have actually fixed the IOCP issues for many people and appear to have made hmail much faster for some reason. I assume because of thrashing that wasn't always causing crashes but was causing hmail to be slower under certain conditions. Just like the earlier submitted "fix" I sent you messages about my changes asking for input but you never responded. (When I say did not respond I mean with useful information as in you put thought into it vs "ok" canned response.) Search your chat history for CriticalSection or look for the CriticalSection's added to the code such as in TCPConnection.cpp Again they might not be proper fixes but I have yet to see a report of an IOCP crash for anyone on the builds I made with those CriticalSection's added so until a better solution comes up it's considered a fix.
Bill

Post by **martin** » 2014-09-07 09:55

I replied in this thread Bill:
https://hmailserver.com/forum/viewtopic ... 42#p166142

ehych · Post by **ehych** » 2014-09-09 01:56

I'm using now STARTTLS and it looks like I'm having some issues. I will first describe the configuration I have:

-hMailServer 5.5B2074
-Starttls enabled as optional on ports: 25, 143 and 587
-Using wildcard valid certificate.
-Check the 'Use STARTTLS if available' box on the smtp options.
-Using a cipher list recommended by mozilla in the security box:

Code: Select all

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK;

The problems are the following:
-Sometimes receive the error 335544539 described as short read when attempting to establish the SSL handshake, perhaps the handshake timeout is set to low.
-Mails from and to Gmail are received and sent correctly using the ECDHE cipher but mails from and to outlook or hotmail do not use the TLS connection.
-On the logs the mails from iCloud are not received by TLS because there's no cipher shared, but I don't know which cipher they tried to use. Could we have on the logs the cipher they tried to use and also the ones they used when establishing the connection correctly?

Thank you all for the great work you're doing. Cheers.

Post by **martin** » 2014-09-09 09:59

The error 335544539 could mean that there was just a disconnection. This could be caused by a range of reasons, and I'm not sure it's actually an error. This is not logged as an error, right?

Can you post logs for this? Would be interested in seeing what it looks like when you try to deliver to Hotmail/Outlook.com for example, since I've tested this myself with the same build, and I can see that the encrypted connection is used.

prisma · Post by **prisma** » 2014-09-09 14:43

I figured out a possible problem:

I send a test mail from my business account to my private account using B2074. hmailserver seems to do not use encryption to deliver the message to our ISP relayer although STARTTLS is required:

Code: Select all

Received: from mi008.mc1.hosteurope.de ([80.237.138.247])
	by yyy.webpack.hosteurope.de running ExIM with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	id xxx; Tue, 09 Sep 2014 14:17:32 +0200
Received: from mout.kundenserver.de ([212.227.17.10])
	by yyy.webpack.hosteurope.de (mi008.mc1.hosteurope.de) with esmtps (TLSv1:DHE-RSA-AES256-SHA:256)
	id xxx
	for yyy@yyy.net; Tue, 09 Sep 2014 14:17:32 +0200
Received: from mailserver.xxxxx.local (HSI-KBW-109-193-xxx-xxx.hsi7.kabel-badenwuerttemberg.de [109.193.xxx.xxx])
	by mrelayeu.kundenserver.de (node=mreue104) with ESMTP (Nemesis)
	id xxxxx; Tue, 09 Sep 2014 14:17:30 +0200
Received: from [192.168.1.30] (pc-xxxx.xxxxx.local [192.168.1.30])
	by mailserver.xxxxx.local with ESMTPSA
	; Tue, 9 Sep 2014 14:17:46 +0200

But 1und1 offers starttls. Check it with:

Code: Select all

openssl s_client -host smtp.1und1.de -port 25 -starttls smtp

Even though I use auth.smtp.kundenserver.de (which is aliased by mrelayeu.kundenserver.de, see above) instead auf smtp.1und1.de for relayer the mail is delivered unencrypted. In which Log I can see, whether encryption is really used or not? At the moment I have to believe in the header infos....

Possibly it's related to a cert check. But for routes I would expect no delivery in the case the hostname doesn't fit... or not?
What's up?

percepts · Post by **percepts** » 2014-09-09 15:14

tcp, smtp, debug logs should be on. (debug should show cert handshake I think)

Where you define your relayer, which port do you specify? have you ticked "server requires authentication" and have you tried using "starttls optional" so that hmail tries discovery of what your relayer requires? And does relayer require SSL on port 465 and not starttls ?

please post screen print of smtp delivery of email panel

Post by **martin** » 2014-09-09 15:19

Sounds strange Prisma,

Enable all logging (Settings -> Logging in hMailServer Administrator), reproduce the issue and then send me the log at knafve@gmail.com or martin@hmailserver.com.

You've selected "Connection security: STARTTLS (Required)" under Settings -> SMTP -> Delivery of email, right?

I just tried setting up a server without STARTTLS support, configured hMailServer to require it and the message bounced back as expected. Could be some other thing though, such as caused by a failed certification verification.

prisma · Post by **prisma** » 2014-09-09 15:40

martin wrote:You've selected "Connection security: STARTTLS (Required)" under Settings -> SMTP -> Delivery of email, right?

Yes.

Because we have some external accounts hosted by the ISP directly we need also a route to this external business accounts. Within this route STARTTLS is also required. Proofed it twice.
Because my private account doesn't match the business route it won't be used. No question. But possibly this weird setup it's the reason for hmails confusion...

I'll send you the logs. I hope it's only the Nemesis mailserver writing wrong info into the header...

Post by **martin** » 2014-09-09 15:48

There are automated tests for hMailServer which confirms that messages bounces if you've chosen STARTTLS Required but the server does not support it. But of course, could be that the tests are incomplete as well.

I hope it's only the Nemesis mailserver writing wrong info into the header...

I assume you're talking about the ESMTP vs ESMTPS... That's specified in RFC3848 and a mail server can be 100% properly implemented without implementing that specification. So it wouldn't really be "wrong" behavior not to include it as far as I can tell. But let's have a look in the logs.

prisma · Post by **prisma** » 2014-09-09 16:00

Sent you the logs. Looks like the ISPs mailserver is writing wrong info into the header, isn't it?

Post by **martin** » 2014-09-09 16:17

Yes. hMailServer does use both STARTTLS and AUTH for the connection, so if the ISP server implemented RFC3848 the Received header would contain ESMTPSA. But the server does not seem to implement RFC3848. (So not an issue with hMailServer)

percepts · Post by **percepts** » 2014-09-09 16:27

don't know if its any help but following gave exact same error code. Not using relay or route.

viewtopic.php?p=165617&sid=73347a2d83fa ... 20#p165617

because I used "starttls if available" it retried using esmtp which worked.

An other send worked OK using esmtps. i.e. problem disappeared and I haven't seen it since.

looks like it was some kind of transmission/connection issue (short read).

enable tcp/ip logging at all times for better indication of failures like this.

japi · Post by **japi** » 2014-09-09 16:42

Regarding the short read issue:
This reminds me of a bug we had in the experimental build too.
I did an short analysis here: https://hmailserver.com/forum/viewtopic ... 49#p163349
The error message is not the same, but the symptoms sound simmilar.
It seemed to happen if the server sent an TCP ACK without further content.
The content of the packet seemed to be not validated to actually contain "220 Ready to start TLS".

In this case maybe it is also just an TCP ACK packet which leads to the "short read" error. Since those packets are not always sent, the error does only pop up sometimes.

prisma · Post by **prisma** » 2014-09-09 16:47

THX for cross check, martin.

ehych · Post by **ehych** » 2014-09-09 17:15

martin wrote:The error 335544539 could mean that there was just a disconnection. This could be caused by a range of reasons, and I'm not sure it's actually an error. This is not logged as an error, right?

Can you post logs for this? Would be interested in seeing what it looks like when you try to deliver to Hotmail/Outlook.com for example, since I've tested this myself with the same build, and I can see that the encrypted connection is used.

Here is the log. The Outlook session is the 13475 and you were correct, an encrypted connection is used. I was wrong because I didn't see that the short read was coming from my internal lan (session 13473, 13474) I still don't understand why there's a disconnection in the internal sessions. Thank you for the response and I'll try and pinpoint what's happening.

BTW, is there any chance to log the asked/used ciphers?

Code: Select all

"DEBUG" 992 "2014-09-09 09:53:27.902" "Creating session 13475"
"TCPIP" 992 "2014-09-09 09:53:27.902" "Connecting to 65.55.37.104:25..."
"DEBUG" 2792 "2014-09-09 09:53:27.902" "The read operation failed. Bytes transferred: 0 Remote IP: 192.168.1.1, Session: 13473, Code: 335544539, Message: short read"
"DEBUG" 2792 "2014-09-09 09:53:27.902" "Closing TCP/IP socket"
"DEBUG" 2792 "2014-09-09 09:53:27.902" "Ending session 13473"
"DEBUG" 3496 "2014-09-09 09:53:27.902" "Creating session 13476"
"TCPIP" 3496 "2014-09-09 09:53:27.902" "TCP - 192.168.1.1 connected to 192.168.1.10:993."
"DEBUG" 3496 "2014-09-09 09:53:27.902" "TCP connection started for session 13474"
"DEBUG" 3496 "2014-09-09 09:53:27.902" "Performing SSL/TLS handshake for session 13474. Verify certificate: False"
"DEBUG" 3496 "2014-09-09 09:53:28.027" "TCP connection started for session 13475"
"DEBUG" 2792 "2014-09-09 09:53:28.136" "The read operation failed. Bytes transferred: 0 Remote IP: 192.168.1.1, Session: 13474, Code: 335544539, Message: short read"
"DEBUG" 2792 "2014-09-09 09:53:28.136" "Closing TCP/IP socket"
"DEBUG" 2792 "2014-09-09 09:53:28.136" "Ending session 13474"
"DEBUG" 3496 "2014-09-09 09:53:28.136" "Saving message: {1947B3DB-B641-48CE-AAEB-39E57038FCBD}.eml"
"SMTPC" 2916 13475 "2014-09-09 09:53:28.152" "65.55.37.104" "RECEIVED: 220 COL004-MC3F4.hotmail.com Sending unsolicited commercial or bulk e-mail to Microsoft's computer network is prohibited. Other restrictions are found at http://privacy.microsoft.com/en-us/anti-spam.mspx. Tue, 9 Sep 2014 07:52:18 -0700 "
"SMTPC" 2916 13475 "2014-09-09 09:53:28.152" "65.55.37.104" "SENT: EHLO ****.***.***"
"DEBUG" 3496 "2014-09-09 09:53:28.199" "Creating session 13477"
"TCPIP" 3496 "2014-09-09 09:53:28.199" "TCP - 192.168.1.1 connected to 192.168.1.10:993."
"DEBUG" 3496 "2014-09-09 09:53:28.199" "TCP connection started for session 13476"
"DEBUG" 3496 "2014-09-09 09:53:28.199" "Performing SSL/TLS handshake for session 13476. Verify certificate: False"
"SMTPC" 2916 13475 "2014-09-09 09:53:28.277" "65.55.37.104" "RECEIVED: 250-COL004-MC3F4.hotmail.com (3.20.0.138) Hello [201.151.131.113][nl]250-SIZE 36909875[nl]250-PIPELINING[nl]250-8bitmime[nl]250-BINARYMIME[nl]250-CHUNKING[nl]250-STARTTLS[nl]250-AUTH LOGIN[nl]250-AUTH=LOGIN[nl]250 OK"
"SMTPC" 2916 13475 "2014-09-09 09:53:28.277" "65.55.37.104" "SENT: STARTTLS"
"DEBUG" 2792 "2014-09-09 09:53:28.417" "Closing TCP/IP socket"
"DEBUG" 2792 "2014-09-09 09:53:28.417" "Ending session 13476"
"DEBUG" 3496 "2014-09-09 09:53:28.417" "Creating session 13478"
"TCPIP" 3496 "2014-09-09 09:53:28.417" "TCP - 192.168.1.1 connected to 192.168.1.10:993."
"DEBUG" 3496 "2014-09-09 09:53:28.417" "TCP connection started for session 13477"
"DEBUG" 3496 "2014-09-09 09:53:28.417" "Performing SSL/TLS handshake for session 13477. Verify certificate: False"
"SMTPC" 2916 13475 "2014-09-09 09:53:28.464" "65.55.37.104" "RECEIVED: 220 SMTP server ready"
"DEBUG" 2916 "2014-09-09 09:53:28.464" "Performing SSL/TLS handshake for session 13475. Verify certificate: True, Expected remote host name: mx4.hotmail.com"
"DEBUG" 2916 "2014-09-09 09:53:28.636" "The read operation failed. Bytes transferred: 0 Remote IP: 192.168.1.1, Session: 13477, Code: 335544539, Message: short read"
"DEBUG" 2916 "2014-09-09 09:53:28.636" "Closing TCP/IP socket"
"DEBUG" 2916 "2014-09-09 09:53:28.636" "Ending session 13477"
"DEBUG" 3496 "2014-09-09 09:53:28.636" "Creating session 13479"
"TCPIP" 3496 "2014-09-09 09:53:28.636" "TCP - 192.168.1.1 connected to 192.168.1.10:993."
"DEBUG" 3496 "2014-09-09 09:53:28.636" "TCP connection started for session 13478"
"DEBUG" 3496 "2014-09-09 09:53:28.636" "Performing SSL/TLS handshake for session 13478. Verify certificate: False"
"DEBUG" 3496 "2014-09-09 09:53:28.777" "Certificate verification succeeded for session 13475."
"DEBUG" 3496 "2014-09-09 09:53:28.855" "The read operation failed. Bytes transferred: 0 Remote IP: 192.168.1.1, Session: 13478, Code: 335544539, Message: short read"
"DEBUG" 3496 "2014-09-09 09:53:28.855" "Closing TCP/IP socket"
"DEBUG" 3496 "2014-09-09 09:53:28.855" "Ending session 13478"
"SMTPC" 2916 13475 "2014-09-09 09:53:28.917" "65.55.37.104" "SENT: EHLO ****.***.***"
"SMTPC" 3852 13475 "2014-09-09 09:53:29.074" "65.55.37.104" "RECEIVED: 250-COL004-MC3F4.hotmail.com (3.20.0.138) Hello [201.151.131.113][nl]250-SIZE 36909875[nl]250-PIPELINING[nl]250-8bitmime[nl]250-BINARYMIME[nl]250-CHUNKING[nl]250-AUTH LOGIN[nl]250-AUTH=LOGIN[nl]250 OK"
"SMTPC" 3852 13475 "2014-09-09 09:53:29.074" "65.55.37.104" "SENT: MAIL FROM:<***@***.com>"
"SMTPC" 2792 13475 "2014-09-09 09:53:29.214" "65.55.37.104" "RECEIVED: 250 ***@***.com....Sender OK"
"SMTPC" 2792 13475 "2014-09-09 09:53:29.214" "65.55.37.104" "SENT: RCPT TO:<***@outlook.com>"
"DEBUG" 2972 "2014-09-09 09:53:29.402" "Reading messages from database."
"SMTPC" 2972 13475 "2014-09-09 09:53:29.433" "65.55.37.104" "RECEIVED: 250 ***@outlook.com "
"SMTPC" 2972 13475 "2014-09-09 09:53:29.433" "65.55.37.104" "SENT: DATA"
"SMTPC" 2792 13475 "2014-09-09 09:53:29.589" "65.55.37.104" "RECEIVED: 354 Start mail input; end with <CRLF>.<CRLF>"
"SMTPC" 2792 13475 "2014-09-09 09:53:29.589" "65.55.37.104" "SENT: [nl]."
"SMTPC" 2916 13475 "2014-09-09 09:53:30.089" "65.55.37.104" "RECEIVED: 250 <6C96F28D-873D-4262-BBDE-0318B2DF8FCD@***.com> Queued mail for delivery"
"SMTPC" 2916 13475 "2014-09-09 09:53:30.089" "65.55.37.104" "SENT: QUIT"
"SMTPC" 3852 13475 "2014-09-09 09:53:30.277" "65.55.37.104" "RECEIVED: 221 COL004-MC3F4.hotmail.com Service closing transmission channel"
"DEBUG" 3852 "2014-09-09 09:53:30.292" "Closing TCP/IP socket"
"DEBUG" 3852 "2014-09-09 09:53:30.292" "Ending session 13475"

myname · Post by **myname** » 2014-09-13 16:02

First of all I would like to thank you for the 2074 version where STARTTLS already works !
But Ehych is right in saying that you can not use any "DH" for the connection to hMailServer. So if the window SSL / TLS ciphers sets cipher containing any "DH" the connection fails:
openssl s_client -connect mail.******.cz:465
Loading 'screen' into random state - done
CONNECTED(0000018C)
10408:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:.\ssl\s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 319 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE

But the point is that if hMailServer as a client, a mail is sending with encryption using "DH" nothing problem and use it for encryption. Thus, the above-described problem with PFS is only when the hMailServer server role, if mail receiving.

Post by **martin** » 2014-09-13 16:09

myname wrote:But the point is that if hMailServer as a client, a mail is sending with encryption používahící "DH" nothing problem and use it for encryption. Thus, the above-described problem with PFS is only when the hMailServer server role, if mail receiving.

Excuse my ignorance, but is this a problem? There's a lot of available ciphers and I'm not sure you actually need to use the one which does not work?

myname · Post by **myname** » 2014-09-13 16:48

Perfect Forward Secrecy is need to leave connection private. For example: http://vincent.bernat.im/en/blog/2011-s ... crecy.html

But I rather it was a this. According to me indicates a problem in the implementation of TLS in hMailServer when going message sending PFS works but not when receiving.

Post by **martin** » 2014-09-13 16:59

Interesting, will have a look.

Post by **martin** » 2014-09-14 10:03

Alright, done some reading and got a dummy implementation to work. Also looked into how to include the cipher in the received header. I think I will leave these two for version 5.6. Version 5.6 will probably just include this and an upgrade of the build system to use VS2013, so time-wise there's no huge difference.

I am still a bit confused about DH though and need to learn more. People recommend using 2048bit DH bit primes. This takes quite some time to generate so I can't really let hMailServer do that during startup or runtime. I've read that you could just use some primes generated by some one else (as long as you know they are not from an attacker), so it would seem like I could generate the DH primes and ship them with hMailServer.

This appears to be what Postfix is doing, and they tell users that "you may want to regenerate your primes periodically" in their documentation. (This is done by replacing the dh files)

Do you have any experience?

ulicky · Post by **ulicky** » 2014-09-14 13:11

Hi,

you can use this test: https://ssl-tools.net/mailservers perfect forward secrecy doesnt work no matter what ciphers suite I try.
I use 2 sets from here https://wiki.mozilla.org/Security/Server_Side_TLS
Compatible one is working but not using ECDHE, more strict version doesnt work at all, because is built on ECDHE.
This is when server is acting as server. Where server is sending mail to other server supporting ECDHE it is working fine.

Post by **martin** » 2014-09-14 16:35

ulicky, as I mentioned I've spent some time and got a dummy implementation to work, so I know why it currently does not work in hMailServer - it currently does not work because it's not implemented - hMailServer needs to provide OpenSSL with a large prime number to be used for this purpose. I created a dummy implementation of this got it to work.

I'm more concerned about how those prime numbers should be generated or shipped with hMailServer. So I was more looking to see if someone has experience with how other mail servers do it. I've read about how Postfix do it and they appear to be shipping the prime numbers with the software.

So my question is more:
- Have anyone here used PFS with another mail server and how did you configure it? Did you generate the prime numbers yourself or use a set bundled with the software?

myname · Post by **myname** » 2014-09-14 17:45

Martin, according to me, it's like this.
DH file should be 2048 bytes big. Just be generated only once since it is not used as a prime number, but the base for generator of prime numbers.
Of course may be somewhere in the item advaced security menu button regenerate DH file. But it then I think, that hMailServer openssl.exe file must contain in order to generate the DH file (https://www.openssl.org/docs/apps/dhparam.html).
Generating DH file takes quite a long time that I had with DH file periodic creating concern about functionality. Moreover, as I wrote under normal circumstances there is no reason to re-create the DH file.

myname · Post by **myname** » 2014-09-14 19:30

I just can think of when you will create a new version in VS why not use "SslStream Class" instead of openssl.

https://www.simple-talk.com/dotnet/.net ... ework-4.0/
http://msdn.microsoft.com/en-us/library ... .100).aspx

Think of it, please, only as an idea.

japi · Post by **japi** » 2014-09-14 21:07

I'm using a DH file for my openvpn server.
It is generated during first time setup only and is a manual step (running the "build-dh" batch-file, which basically just uses openssl: "openssl dhparam -out PATH/dh2048.pem 2048").
The DH file is not included in the zip-file/setup there, but the step to build the file is included in the installation guide.

mattg · Post by **mattg** » 2014-09-15 00:10

Not for traditional email, but I have seen similar encryption established by forcing the installing user to move the mouse and to type 'random' giberish on the keyboard. Takes about two minutes of giberish or mouse twirling, but only happens once on install of the product.

STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?

Re: STARTTLS feedback?