mailcatcher icon indicating copy to clipboard operation
mailcatcher copied to clipboard

SSL/TLS connection

Open sagikazarmark opened this issue 11 years ago • 13 comments

It would be great if secure connections could also be tested.

sagikazarmark avatar Jun 12 '14 10:06 sagikazarmark

Agreed, this is going on the list.

sj26 avatar Jul 30 '14 05:07 sj26

+1 would love to see this.

ghuntley avatar Feb 13 '15 09:02 ghuntley

+1 would be very useful!

chrispappas avatar Feb 16 '15 20:02 chrispappas

+1 Yes, this would be very helpful.

styks1111 avatar Apr 26 '15 20:04 styks1111

:+1:

arosenhagen avatar Sep 21 '15 10:09 arosenhagen

I'm not sure if I understand. Consider a case:

  1. Someone sniffing SSL connection. HTTP content is encrypted so he see nothing.
  2. However he has access to TCP/IP so he can get address and port of the packet destination
  3. he go this address and this port and get all data which was hidden by SSL So isn't SSL pointless in mailcatcher?

dominh avatar Jan 04 '17 17:01 dominh

@dominh Mostly. It would be a little more difficult for the man-in-the-middle if he had to guess the right hostname, in case of a SNI configuration.

This feature makes sense in combination with an additional (basic) auth protection. That could be implemented in mailcatcher as well.

But why not just run a reverse proxy (e.g. nginx) in front of it? That can be configured to do both the SSL termination and basic auth.

djmaze avatar Jan 04 '17 18:01 djmaze

This is not for HTTP, but for SMTP over TLS and STARTTLS, for testing your mail settings and libraries.

I agree that reverse proxying from nginx is better for HTTPS, and I wouldn't recommend exposing mailcatcher itself outside a development environment without something else acting as a proxy with authentication. :-)

sj26 avatar Jan 05 '17 05:01 sj26

@dominh: TLS for MailCatcher is about testing only, in ones' dev env, not about real usage (to me at least).

In a prod env, TLS is required. And then it's good to be able to test, in one's dev/test env, that one's app server does work with TLS. For example, with Apache Commons Email, there're config values related to TLS, STARTTLS and SSL and port numbers, and nice to be able to verify that one's config is correct — e.g. by connecting to MailCatcher over TLS.

kajmagnus avatar May 28 '18 09:05 kajmagnus

Hello all,

I have added a new PR https://github.com/sj26/mailcatcher/pull/386 tonight using the MidiSmtpServer gem. It will work as expected and allows STARTTLS as well as AUTH on SMTP. All checks have been passed.

Maybe you find this helpful.

Cheers Tom

TomFreudenberg avatar Nov 17 '18 00:11 TomFreudenberg

Hi,

So isn't this issue a duplicate of #386?

tfactor2 avatar Mar 31 '21 16:03 tfactor2

Hi @tfactor2

It is not a duplicate because Samuel @sj26 won't accept the PR #386 from my side (check comment: https://github.com/sj26/mailcatcher/pull/386#issuecomment-573477686)

So the issue for mailcatcher is stil open even when the PR had solved that and some other issues as well.

Nothing to wonder about - I am a bit sad about that - but it's Samuels project.

Cheers Tom

TomFreudenberg avatar Apr 05 '21 11:04 TomFreudenberg

Clear, thanks @TomFreudenberg,

BTW1: We decided to keep using mailcatcher despite the fact that on prod we are using TLS. To really test communication the mail server used for testing should be the same as the prod one. Out of TLS itself, there could be other things that may break, e.g. mismatch of TLS versions/ciphers. So, overcomplicating development configuration is kind of useless.

BTW2: For docker environments, I'd rather go towards standard linux smtp servers (e.g. exim4) and integrate simple webmail, see https://github.com/hauptmedia/docker-mailcatcher. It's quite trivial to add TLS there. IMHO and with all respect to the author of the project as without docker the sj26/mailcatcher it's indeed a very useful tool.

tfactor2 avatar Apr 21 '21 18:04 tfactor2