- 최신
- 최다 투표
- 가장 많은 댓글
Hi, you should implement what is described in this blog post to identify the faulty TLS clients: https://aws.amazon.com/blogs/mt/using-aws-cloudtrail-lake-to-identify-older-tls-connections-to-aws-service-endpoints/
It is based on CloudTrail Lake and gives you a holistic view on this issue
Best,
Didier
This only works for management events, not API data events. When sending through the API (SendRawEmail) this doesn’t log the send events.
I answered a similar question here: https://repost.aws/questions/QULhXMQHooRye2QtF_xXeQAQ/how-to-see-cloudtrail-of-ses-calls-sendrawemail-re-tls-1-1#ANkYu8ryN7RZeWWJSNvZAJig.
Hope it helps you.
Hi, in our case emails with were sent from java with version TLSv1 and was fixed adding to the code
mail.smtp.ssl.protocols=TLSv1.2
Regarding how to identify the instances where the emails were sent, we followed this guide https://www.netmeister.org/blog/tcpdump-ssl-and-tls.html
In brief, with this tcpdump you'll capture TLSv1 and TLSv1.1 negotiation:
tcpdump "tcp port 587 and (tcp[((tcp[12] & 0xf0) >>2)] = 0x16) && (tcp[((tcp[12] & 0xf0) >>2)+9] = 0x03) && ( (tcp[((tcp[12] & 0xf0) >>2)+10] = 0x01) || (tcp[((tcp[12] & 0xf0) >>2)+10] = 0x02))" -X
and with this tcpdump you'll capture TLSv1.2 negotiation packets
tcpdump "tcp port 587 and (tcp[((tcp[12] & 0xf0) >>2)] = 0x16) && (tcp[((tcp[12] & 0xf0) >>2)+9] = 0x03) && (tcp[((tcp[12] & 0xf0) >>2)+10] = 0x03)"
Regards
관련 콘텐츠
- AWS 공식업데이트됨 9달 전
- AWS 공식업데이트됨 일 년 전
Is this for inbound SMTP messages, or are you using the API
SendRawEmail
to send messages?Following.
Same story here. We've tried CloudWatch / CloudTrail as noted in the docs to get more information, but no TLS data listed in CW/CT. Based on only a message id from the mailed log rows, it's undoable to find the source. In our own case we are sending with the API SendRawEmail.