I'm trying to collect information from the Exchange protocol logs to identify systems using outdated TLS 1.0 before upgrading from 2016 to Exchange 2019. I am able to use get-childitem and select-string to search the smtpreceive log files for the SP_PROT_TLS1_0_SERVER string, however what I would ultimately like to do would be to search the Exchange smtpreceive transport logs for the string SP_PROT_TLS1_0_SERVER. From the hits for SP_PROT_TLS1_0_SERVER, I would like to use the session-id to collect EHLO and MAIL FROM information and record all three values in a csv file so they can be verified in the transport logs for accuracy. So far I've tried to load all fields of the smtpreceive files into a variable, but something's not right and I'm not getting any output.
You would need to trawl through Exchange Protocol Logs Scanning for sent and received traffic (Mail Flow via SMTP Logging)
Exchange Server TLS guidance Part 2: Enabling TLS 1.2 and Identifying Clients Not Using Ithttps://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-server-tls-guidance-part-2-enabling-tls-1-2-and/ba-p/607761
Exchange Server: Search message tracking logs https://learn.microsoft.com/en-us/Exchange/mail-flow/transport-logs/search-message-tracking-logs?view=exchserver-2019
Analyzing the protocol logs and Message tracking logs in Exchange 2013 https://social.technet.microsoft.com/wiki/contents/articles/23182.analyzing-the-protocol-logs-and-message-tracking-logs-in-exchange-2013.aspx
Example entries from Exchange Server 2010
A server sending mail to another system using TLS 1.2:
2018-02-22T13:53:10.494Z,<CONNECTORNAME>,08D578EB9C3F6C39,28,10.0.0.240:15443,192.168.1.42:25,*,,"TLS protocol SP_PROT_TLS1_2_CLIENT negotiation succeeded using bulk encryption algorithm CALG_AES_256 with strength 256 bits, MAC hash algorithm CALG_SHA_384 with strength 384 bits and key exchange algorithm CALG_ECDHE with strength 384 bits"
A server receiving mail from another system using TLS 1.2
2018-02-22T13:50:37.681Z,SERVERNAME\CONNECTORNAME Internet,07C578BB0E912319,22,10.0.0.241:25,192.168.1.102:63767,*,,"TLS protocol SP_PROT_TLS1_2_SERVER negotiation succeeded using bulk encryption algorithm CALG_AES_256 with strength 256 bits, MAC hash algorithm CALG_SHA_384 with strength 384 bits and key exchange algorithm CALG_ECDHE with strength 256 bits"
SMTP Log Parsing Script WebSites
https://scriptolog.blogspot.com/2007/08/smtp-log-parsing.html
https://www.axigen.com/community/t/made-a-powershell-script-to-parse-smtp-receiving-log/512
Related
I know this topic has been covered comprehensively on SO and several other forums by now. I'm hoping someone can shed some light on my issue. TL;DR: I can get this script to see if a URL is valid when the server uses Tls1.2, but not a URL where the server uses Tls1.2 and Tls1.3.
I'm writing a script for a lowest common denominator audience (Win7, .NET Framework 4.8, WMF 3.0/4.0, all updates installed as of 12/2022) and part of the script checks to see if a given KB update has a support page and/or a MS update catalog download link using Invoke-WebRequest.
I can successfully test https://www.catalog.update.microsoft.com/Search.aspx?q=KB2506143 to see if it has any download buttons.
This particular search result does not have any download buttons/links.
Initially I received a Could not create SSL/TLS secure channel error, but resolved this by including this in the script:
[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor [System.Net.SecurityProtocolType]::Tls12
I cannot test https://support.microsoft.com/en-us/kb/2506143 to see if the URL exists or not. I still receive the Could not create SSL/TLS secure channel error.
When I use [Net.ServicePointManager]::SecurityProtocol = 'Tls13' I get a different exception (expected on Win7):
System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm
Every other combination of SecurityProtol produces the SSL/TSL secure channel error message.
support.microsoft.com looks like it uses Tls 1.2 and Tls 1.3.
www.catalog.update.microsoft.com looks like it uses Tls 1.2 only.
I'm open to other methods simply to check if a URL exists in PowerShell 3.0/4.0 but have come up empty.
I'm certain I'm missing a crucial detail in terms of comparing both SSL reports. I assumed that I would be able to use Invoke-WebRequest using Windows 7 and Tls1.2 (with .NET 4.8 installed and after registry edits, etc) with both websites, but only the catalog URL is working for now. I tried a Win8.1 VM for kicks and got the same results - catalog URL works but the support URL still fails with the SSL/TLS secure channel error. This works on Windows 10 for me though.
What am I overlooking or missing (other than there are people/companies using Win7 that shouldn't be)?
In this case, the issue is not about the TLS 1.2/1.3 Protocol it is about the Cipher Suites that are supported.
The TLS protocol supports many different methods for exchanging keys, encrypting data, and authenticating message integrity. As a Protocol, it defines how packets move between you and the server, the Cypher suites supported between both client and server, and how to select the encryption protocol. Earlier versions of the Protocol were susceptible to protocol related issues like Man-In-The-Middle attacks (and nothing related to encryption). TLS 1.2+ (with certain Cipher Suites) is regarded as secure.
Protocols are like roads and highways. They have pavement, lines, and markings that allow cars and trucks to move from one point to the next. Earlier protocols didn't have protective guard rails, new ones now do.
Cipher Suites are like the cars and trucks. There are dozens of ways to encrypt a packet of data. Some have elliptic curves, some do not. Some have government level encryption with huge number of bits, some have less. Likewise some cars have no doors on them, and some trucks have 256bit steel reinforced doors on them. They both can go down the same protocol highway, but one of these is not secure.
In this case, the web server is saying that it allows both TLS 1.2 and 1.3 protocols (highways with guard rails). It is also saying that it only allows certain secure Cipher Suites that have not been deemed insecure (e.g. no cars without doors are allowed).
The Cipher Suites allowed on this site is:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp256r1 (eq. 3072 bits RSA)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp256r1 (eq. 3072 bits RSA)
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) ECDH secp256r1 (eq. 3072 bits RSA)
Since new Cipher Suites are developed all the time, Windows 7, 8, and 8.1 while supporting the TLS 1.2 protocol don't have the newest developed Cipher Suites installed to actually know how to decrypt the packets (e.g. fancy new alien space ships are allowed to travel down the TLS 1.2 protocol highway, but your old school town doesn't know how to open one because you don't have the newest elliptical curve spanners). See Windows 7 Supported Cipher Suites.
In this case, the new Cipher Suites weren't developed and installed until Windows 10. See Windows 10 Supported Cipher Suites. Remember Windows 10 came out 10 years after Windows 7, so not having the latest technology is the situation here, and since it is out of mainstream support, it won't be fixed. Basically, this website will never be able to visit this particular website.
I'm working on a Laravel 4.2 application that needs to be able to send emails. When the SwiftMailer component contacts the Microsoft Exchange server we use here it's receiving the following reply:
* OK The Microsoft Exchange IMAP4 service is ready.
* BYE Connection is closed. 13
My understanding is that I should be seeing SMTP response codes 220 and 221 instead of those asterisks; the SwiftMailer module is throwing an Exception when it receives the message without the codes.
I'm trying to do some investigation before bugging my coworker who manages the server in question. Does anybody have an idea how this substitution of asterisks for the codes may be occurring? I'm confident based on reviewing the code in SwiftMailer than this isn't occurring to the text of the response after it's received. Is this some sort of Exchange server security feature I'm unfamiliar with (and can't imagine the value of)?
The messages indicate that you are talking to an IMAP server, not an SMTP server. I'm guessing you put the wrong port number somewhere.
Odds are that you've got an "intelligent" network device between you and the server that's doing traffic inspection. I've seen this with Cisco devices, where the SMTP connection banner is replaced with a string of asterisks and all the command words in the SMTP traffic are replaced with "XXXX".
I configured exim mail server on centos. It is working with no encryption type. But not with SSL and TLS. I din't get correct solution for this type of error. Can anyone tell solution and why this error message in exim main.log file?
The error message is like below in the exim main.log file.
2015-03-17 10:34:16 SMTP protocol synchronization error (input sent without waiting for greeting): rejected connection from H=acp-node [10.7.2.137] input="\026\003\001"
(input sent without waiting for greeting) ... input="\026\003\001"
In short: You are trying to use implicit TLS on a port where explicit TLS is needed.
In detail: There are two ways to use TLS with SMTP:
implicit TLS, that is TLS from start. This is used on port 465 (smtps). This mode is in some SMTP stacks simply called "SSL".
explicit TLS, that is start with plain SMTP and upgrade to TLS with the STARTTLS command. This is used on ports 25 (smtp) and 587 (submission). This mode is in some SMTP stacks simply called "TLS".
If you look around at the questions regarding use of SMTP with TLS you will find lots of confusion about how to use these modes with the various setups. And you will find lots of bad code which tries to use implicit TLS where explicit TLS is needed.
What you see is the result of the client trying to use implicit TLS on a port not suitable for this. \026\003\001 (or hex 16 03 01) is the start of a TLS 1.0 handshake and input sent without waiting for greeting refers to the fact, that the client is sending data first without waiting for the server to send the (plain text) SMTP greeting.
Judging from the error log entry, your mail client 10.7.2.137 is trying to establish a secure (TLS) connection but your Exim server is not expecting it.
Most probably, TLS is not configured properly in your Exim configuration file. You can refer to http://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html for tutorial.
The solution is, therefore, to edit your Exim configuration file, making sure TLS certificates are defined and tls_advertise_hosts is set; and then restart Exim.
I use a SIP server that listens over port 5070 for SIP/TLS requests. I'm trying to trace and analyze why my dialer is not registering over the network through Wireshark.
I've edited all the needed fields in Wireshark's preferences, added the server's private key, edited the SIP TCP and TLS ports (which are 5070 not 5061), and all I'm getting now clearly is the TLS Client Hello and Server responses, but no SIP is showing up, just TCP SYNs and ACKs.
I've searched and tried everything possible, but to no avail - any help would be highly appreciated.
Thanks in advance.
//M
Is the TLS session using a cipher suite with perfect forward secrecy? If that is the case, Wireshark cannot decrypt TLS even with the server private key. Check the cipher suite selected by the server in the ServerHello message for the substring EDH or EECDH, in which case perfect forward secrecy is used. You will have do configure the cipher suites in either the client or the server to not use any EDH and EECDH suites. With OpenSSL, use a cipher suite setting of ALL:-EDH:-EECDH or similar.
With perfect forward secrecy, the client and the server will agree on a shared session key using Diffie-Hellman (DH); the server private key is only used for signing. Without perfect forward secrecy, the shared key is encrypted with the server's public key by the client, and thus can be decrypted by the server (and Wireshark) using the server's private key (assuming the server uses an RSA key).
I am trying to programatically send out ICMPv6 echo requests (ping6) using WinSock2. The ICMPv6 checksum is calculated based on the whole IPv6 packet that will be sent out. For that reason - from what I understand - the OS (kernel?) is supposed to calculate it and write it into the ICMPv6 header when sending the packet.
This works very well on a SUSE Linux Enterprise Server 11, however, Windows XP does not seem to do this. It leaves the checksum to what I set it by default (zero, I analyzed this using Wireshark), thus the receiving end will discard it and not reply.
IPv6 is correctly set up on this WinXP machine. With the help of Wireshark I even found out that it responds correctly to ICMPv6 pings from the SUSE Linux server, sent using the very same code. So it cannot be that Windows XP doesn't support ICMPv6. However, I wonder whether WinSock2 under Windows XP does.
The WinSock2 API does provide the IPPROTO_ICMPV6 protocol which I create my raw socket for. Is there any special socket option I need to set for the ICMPv6 checksum to be calculated automatically, or are there any other tricks?
Most probable reason for the behavior you describe is checksum offloading. It means, checksum calculation might be delegated to networking hardware, so that sniffed packet doesn't contain the correct checksum value. Refer to http://www.wireshark.org/docs/wsug_html_chunked/ChAdvChecksums.html or to http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Checksum_offload