TLS 1.2 & Wireshark Refresher

Overview:  I have lost count of the number of TLS upgrades I have worked on.  The upgrades are easy as long as you understand the basics.  I generally set up a test rig to verify settings, update configurations, and test the traffic.  

Understanding Server and Client Registry Settings for TLS: 

• "Client" registry keys govern outbound protocol availability.
• "Server" registry keys govern which protocols are available for inbound connections.

Check TLS 1.2. connections from a client to a SQL Server:

The client machine hosts a Console/C# Test Rig that is connecting to SQL Server that supports only TLS1.2.  Then, on the client Windows registry settings, you are interested in the TLS1.2/Client/Enabled setting, as shown above.  

• Below is a screenshot of a C# test rig, used to ensure the registry settings are correct (I restart the test rig after I make a change to the client/TLS registry settings.  Running the "Test Connection", tells me outbound traffic is using TLS1.2, the successful connection tells me that SQL Server is accepting TLS1.2 traffic.

If unsuccessful or you want proof: 

Wireshark is a packet capture (PCAP) tool that replicates the network traffic packets as they pass through the machines' drivers/adapters.

• Wireshark is a great tool, and can be used to verify the underlying traffic, in this scenario I have Wireshark on the client machine to capture and analyze the TLS traffic going to the SQL Server generated by the C# test rig.
• Ensure you have the adapters you want to monitor selected, and I have added a filter to only show traffic being sent to the SQL Server using the IP address.  "hosts 10.1.x,25"

Capture the traffic, you'll see the connection being set up in the packet transfer.  The protocol will show TLSv1.2 in Wireshark.

TLS1.2 traffic

TLS1.0 Outbound Traffic

Use Netsh or Pktmon to capture local adapter traffic, then load the logs in Wireshark.  c:> netsh trace start capture=yes from the admin run cmd prompt to capture packets.   Packet Monitor (Pktmon) is also an option.

tcpdump is a good tool. 

More Info:

https://social.technet.microsoft.com/wiki/contents/articles/41703.sql-server-securing-network-communications.aspx

DevOps Tooling

DevOps Tooling Notes

DevOps Tooling is broken down into the following areas. Note that the tools often overlap in function.  The list is not exhaustive, and these are the more common tools I have come across.

1. Version Control: TFS, Git, SVN, ...
2. Bug Tracking: ServiceNow, Jira, ZenDesk
3. Continuous Testing: Selenium, Jasmin or Mocha or Unit.js (JavaScript testing), NUnit, Web Tests (Visual Studio), SpecFlow
4. Continuous Integration (CI): TeamCity, Jenkins, Azure DevOps (bigger) 
5. Configuration Management and Deployment:  Puppet, Chef, ANSIBLE, SALT  (all installed on Linux, obviously work on Windows environments)
6. Containers: Docker, Kubernetes, Microsoft Containers. I think the Azure AKS is pretty much containers for Azure now.
7. Other:  PowerShell, VMWare, HyperV

RESTful API Tooling

1. Swagger - awesome.  Swagger is a set of tools that help document, build and test your API  (Your API conforms to the OpenAPI specification or Swagger specification).  Great way to get a contract for users of the API early on.  Updated 2019/11/25:  Link to Swagger post
2. Swagger UI, Swagger Integrator,...
3. Apiary - UI to create an API and publish with mocks.  I prefer Swagger or, for simple projects, APIM.
4. API Management (APIM) - a flexible Azure service for bringing together multiple API securely.  Same as MuleSoft.  Can import OpenAPI v2 or v3 to create a hosted API.  Can mock and build a test tool.
5. RAML is an alternative to Swagger and Apiary (never used)
6. Blueprint - API documentation tool.  Pretty simple and nice results.
7. Postman - send HTTP requests to the API.  Postman is a REST client that helps you check your API.  This is my main tool for testing and exploring REST-based API's.  
8. SoapUI - if working with SOAP/XML.
9. Slate - API documentation - I always use OAS/OpenAPI/Swagger.
10. Fiddler - I'm old school and still love Fiddler and its capabilities.  Fiddler is an excellent HTTP debugger.  
11. BURP - an HTTP debugger to review traffic.  I've used BURP for security testing, and it is excellent for API debugging.  
12. Charles is another HTTP debugger (I have never used it).
13. cURL - Command-line tool to test APIs using HTTP; separate executable to run on Windows. Windows 10 has cURL built in.
14. Visual Studio
15. Wireshark - Packet Capture (PCAP) Over the years, I have often needed packet sniffing to troubleshoot issues, and I always turn to Wireshark. I used the tool in the 90s, but it had a different name.  Extremely useful for matters related to firewalls, especially when an environment behaves differently from another working DTAP environment.  With end-to-end encryption, the amount of data that PCAP can capture is no longer as straightforward as it used to be.
16. Tcpdump is another packet sniffer (PCAP)
17. Bruno (May 2025) wow

Testing:
http://www.incyclesoftware.com/2014/02/executing-selenium-ui-tests-release-management/

More Info:
http://blog.sharepointsite.co.uk/2014/02/devops-and-sharepoint.html
http://www.networkworld.com/article/2172097/virtualization/puppet-vs--chef-vs--ansible-vs--salt.html
http://blog.sharepointsite.co.uk/2013/11/iac-presentation-for-sharepoint.html