Amcrest Forum

Thank you for the information that has been provided so far. Our R&D team is evaluating the findings and we will continue providing updates as they come.

Unfortunately, I don't think TLS is the problem. I've tried resetting my Gmail SMTP settings using pretty much all the options...no encryption, TLS, SSL, etc. I've even tried Google's relay servers. Nothing works.

aminco is correct.
I too tried SSL(465) and 'None' before diving deeper and getting focused on TLS.

SSL(465) definitely also fails. So, I dove back in to get a capture of that too.

In SSL(465) we again see Alert (Level: Fatal, Description: Inappropriate Fallback) as the response from the GMail server.

What triggers that in both cases is the Client Hello packet from the camera. The attachment shows a side-by-side comparison of that Client Hello packet for TLS(587) and SSL(465). As you can see, they are identical.

I'm not sure that's any kind of problem. What I'm focused on is the the dark-blue highlighted Version: TLS 1.0 (0x0301). In connections which work (e.g. Outlook to GMail) that says Version: TLS 1.2 (0x0303). And, the response that Hello gets from the GMail server is Server Hello, Change Cipher Spec, Encrypted Handshake Message... after which encrypted data exchange (an e-mail) proceeds normally.

Notice that this changes my previous guess regarding TLS V1.3. Obviously V1.2 works for Outlook to GMail connections. But, Outlook (it seems) doesn't try to fall back to TLS 1.0. It sticks with TLS 1.2.

As for the Amcrest Authentication setting... it's no longer clear what that actually does... is it?

Late entry:
When I refer to Outlook above I mean the Microsoft Office product, not the Outlook setting in the Amcrest camera setup.
Also... smtp.gmail.com will not respond on SMTP(25). I have run a packet trace confirming this (to the extent you can prove a negative). https://support.google.com/a/answer/176600?hl=en
Interestingly... and contrary to the article... smtp-relay.gmail.com will not respond to SYN packets on SMTP(25) either.

Sidenote:
Anyone desperate for a temporary workaround could consider installing a free mail server on some PC in their own network... let the Amcrest send email to that... and configure that mail server to relay to smtp.gmail.com. It works perfectly here.

As a purely academic exercise I even generated a self-signed cert for my locally-installed mail server and configured it to require TLS when receiving mail from the Amcrest over my local net.

I picked hMailServer for this. I'm happy with it but that's not meant as an endorsement. Pick your own.
https://en.wikipedia.org/wiki/Compariso ... il_servers

Great work GRSmith.

I checked my Google smtp TLS 587 port with mailsend. No problem there.

Looking forward to a solution.

Thanks to GRSmith's posts, I just tried creating a new email id in zoho.com, a free email service. It works. Used smtp.zoho.com as SMTP server, TLS for authentication, and 587 for port. It remains to be seen if this works consistently, but my email test succeeded. Holding my breath for now...

I'm not buying Amcrest's claim this is a Google issue, which is preventing gmail accounts from getting email notifications.

I have a Lorex system at home and I use the same gmail settings as I have on my Amcrest system and it works fine. So this is clearly and Amcrest issue to resolve and they're conning us by putting the blame on Google/gmail.

I was curious to compare the failing Client Hello from the camera with a working Client Hello from my local email relay server to GMail. See attachment.

As you see they are extremely similar. Especially notice that blue highlighting. Both working and non-working Hellos specify Version: TLS 1.0 (0x0301) at the point previous mentioned. So, this can't very well be the problem, can it.

Furthermore, in response to the working Client Hello the GMail server is selecting this: Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f). Notice that both working and non-working Hellos offer that Cipher Suite. So, that can't be the problem either.

The working Client Hello does submit a TLS SessionTicket. But, that is only because it has cached information on a previously successful TLS session. You can read about how that works here: https://blog.filippo.io/we-need-to-talk ... n-tickets/. So, it seems that can't be the problem either!

The one intriguing thing I do see is that the camera is offering this in it's list of Cipher Suites TLS_FALLBACK_SCSV (0x5600)... and the working Client Hello does NOT offer that. You can read about this signalling service here: https://tools.ietf.org/html/rfc7507.

It seems that the significant paragraph of that RFC might be this:
o If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the
highest protocol version supported by the server [v1.3 as shown in my first post] is higher than
the version indicated in ClientHello.client_version, the server
MUST respond with a fatal inappropriate_fallback alert (unless it
responds with a fatal protocol_version alert because the version
indicated in ClientHello.client_version is unsupported). The
record layer version number for this alert MUST be set to either
ClientHello.client_version (as it would for the Server Hello
message if the server was continuing the handshake) or to the
record layer version number used by the client.

As far as 'blame' goes, two things there:
1. Amcrest is probably correct. Google likely did change something... that something being to upgrade their SMTP servers to support SSL/TLS V1.3... which is a perfectly responsible thing to do.
2. Unfortunately, it appears that with TLS_FALLBACK_SCSV (0x5600) in the list of Cipher Suites supported by the camera the GMail servers are now obligated to respond with a fatal alert when connections are attempted using any lesser TLS version.

So, to my fur-brain it seems like maybe the Amcrest camera should just stop listing TLS_FALLBACK_SCSV (0x5600) in it's list of supported Cipher Suites. But... the RFC probably offers some better solution. I have read very little of it so far.

If not... then it seems we've come full circle to my original guess which was that Amcrest should upgrade the SMTP client to support SSL/TLS V1.3. That way the cameras could continue to support the fallback signalling service TLS_FALLBACK_SCSV (0x5600).

I hope Amcrest does update the smtp. For now I used outlook.com to get back my email alerts.
Edit: spoke too soon - outlook only worked for a day; now it returns test email failed.

It turns out there is lots of discussion... and further confirmation of the fallback problem... over on ipcamtalk.com.
I discovered this site just this morning (good ol' Google search).
https://ipcamtalk.com/threads/email-notify.39414/page-3

Also... you'll notice numerous mentions of Dahua. Turns out Dahua is an Amcrest OEM. So Amcrest may be dependent on Dahua for providing the fix. But, that is likely good news because the problem is almost certainly affecting more products than just Amcrest-branded products!
https://ipvm.com/reports/dahua-oem