{"id":26965483,"url":"https://github.com/compcode1/wireshark-flow-execution","last_synced_at":"2025-04-03T07:28:55.661Z","repository":{"id":284969723,"uuid":"956659171","full_name":"Compcode1/wireshark-flow-execution","owner":"Compcode1","description":"This project is a continuation of our previous Wireshark flow analysis, where we developed an optimized methodology to track the resolution and connection process of a website.","archived":false,"fork":false,"pushed_at":"2025-03-28T16:30:01.000Z","size":32,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-03-28T17:42:20.975Z","etag":null,"topics":["filtering-algorithm","wireshark"],"latest_commit_sha":null,"homepage":"","language":"Jupyter Notebook","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Compcode1.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2025-03-28T16:23:48.000Z","updated_at":"2025-03-28T16:30:34.000Z","dependencies_parsed_at":"2025-03-28T17:52:30.832Z","dependency_job_id":null,"html_url":"https://github.com/Compcode1/wireshark-flow-execution","commit_stats":null,"previous_names":["compcode1/wireshark-flow-execution"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Compcode1%2Fwireshark-flow-execution","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Compcode1%2Fwireshark-flow-execution/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Compcode1%2Fwireshark-flow-execution/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Compcode1%2Fwireshark-flow-execution/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Compcode1","download_url":"https://codeload.github.com/Compcode1/wireshark-flow-execution/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":246955571,"owners_count":20860299,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["filtering-algorithm","wireshark"],"created_at":"2025-04-03T07:28:55.200Z","updated_at":"2025-04-03T07:28:55.654Z","avatar_url":"https://github.com/Compcode1.png","language":"Jupyter Notebook","readme":"**📌 Wireshark Flow Analysis: Full Reference Summary**\n\nEfficient Tracking of DNS, TCP, TLS, and HTTPS Using Targeted Filtering\n\n**Objective:** This structured methodology provides an efficient and repeatable approach to analyzing secure web traffic, minimizing unnecessary data and refining filtering to obtain only pertinent results. This ensures a clear, systematic method that avoids defaulting to general or inefficient filtering.\n\n**🔹 Step 1: Identifying the Initial Connection Attempt**\n\nPurpose:\n\nTo determine whether the connection was made via IPv4 (A record) or IPv6 (AAAA record), and whether it used QUIC (UDP) or traditional TLS over TCP.\n\nFilter Applied:\ntcp.flags.syn == 1 or udp.port == 443\nWhy?\nFilters only SYN packets (starting a TCP handshake) and UDP packets on port 443 (possible QUIC).\n\nImmediately reveals whether the connection is TCP/TLS or UDP/QUIC.\n\nAlso indicates whether IPv4 (A record) or IPv6 (AAAA record) was used.\n\nFindings:\n✅ The website used IPv4 (A record) over TCP, confirming TLS-based HTTPS rather than QUIC.\n✅ The first connection attempt was to 23.227.38.65 (Reebok’s IPv4 address).\n\n**🔹 Step 2: Analyzing the TCP Handshake**\nPurpose:\nTo confirm that the 3-way TCP handshake (SYN, SYN-ACK, ACK) was successful, ensuring a stable connection was established.\n\nFilter Applied:\n\n(ip.addr == 23.227.38.65) and (tcp.flags.syn == 1 or tcp.flags.ack == 1)\nWhy?\nFilters out irrelevant traffic, keeping only TCP handshake packets related to Reebok’s IP.\n\nEnsures the entire 3-way handshake process can be observed.\n\nFindings:\n✅ SYN, SYN-ACK, and ACK were present, confirming a complete handshake.\n✅ Connection was established on port 443 (HTTPS).\n\n**🔹 Step 3: Verifying the TLS Handshake \u0026 Encryption**\n\nPurpose:\nTo confirm TLS 1.3 is being used, identify the cipher suite, and verify encryption activation.\n\nFilter Applied:\n(ip.addr == 23.227.38.65)\n\n(No need for a more restrictive filter as the TLS handshake packets were already visible.)\n\nWhy?\nThe TLS handshake packets were already within our previously filtered dataset.\n\nWe located Client Hello (Frame 64) and Server Hello (Frame 73) manually without extra filtering.\n\nFindings:\n✅ TLS 1.3 (0x0304) was confirmed as the encryption protocol.\n✅ Cipher Suite Selected: TLS_AES_128_GCM_SHA256 (Provides authenticated encryption and Perfect Forward Secrecy).\n✅ Key Exchange: Server Hello contained a Key Share extension, confirming ephemeral key exchange (likely X25519).\n\n**🔹 Step 4: Confirming the Transition to HTTPS Encryption**\nPurpose:\nTo verify that encryption was fully activated and that the connection transitioned to encrypted HTTPS traffic.\n\nFilter Applied:\n(No additional filter was needed—this was visible from previous filtering.)\n\nKey Packet:\n✅ Frame 77 contained:\n\nChange Cipher Spec message (indicating encryption activation).\n\nApplication Data (meaning all further communication is now encrypted).\n\nFindings:\n✅ TLS 1.3 handshake was complete; encryption is active.\n✅ All further data is encrypted HTTPS traffic and cannot be analyzed without decryption keys.\n\n**🔹 Step 5: Verifying DNS Resolution**\n\nPurpose:\nTo confirm how Reebok’s domain (reebok.com) was resolved to an IP address (23.227.38.65).\n\nFilter Applied:\ndns and dns.flags.response == 1 and dns.qry.name contains \"reebok.com\" and dns.qry.type == 1\nWhy?\nFilters only actual DNS responses (not queries).\n\nFilters only DNS responses related to reebok.com.\n\nFilters only IPv4 (A record) responses, excluding unnecessary IPv6 (AAAA) records.\n\n\n**📌 Understanding How the DNS Response Filter Works**\n\nThis section explains two key filtering behaviors in Wireshark that are essential for accurately analyzing DNS resolution. These clarifications ensure that filtering remains precise and efficient, avoiding unnecessary packet noise.\n\n**🔹 Question 1: Why Are Queries Not Included If dns.qry.name Is in the Filter?**\n\n📌 Key Takeaways:\n\nThe filter we used includes dns.flags.response == 1, which ensures that only DNS responses are displayed and that queries are automatically excluded.\n\nEven though dns.qry.name exists in both DNS queries and responses, this does not override dns.flags.response == 1.\n\nResult: This filter only displays DNS responses that contain reebok.com, ensuring that all unrelated DNS queries are removed.\n\n📌 Rule to Remember:\n✅ If dns.flags.response == 1 is in the filter, DNS queries (dns.flags.response == 0) are always excluded.\n\n**🔹 Question 2: How Does This Filter Exclude IPv6 (AAAA) Records?**\n📌 Key Takeaways:\n\nDNS query types are assigned specific numbers:\n\nIPv4 (A) = 1\n\nIPv6 (AAAA) = 28\n\nThe filter contains dns.qry.type == 1, which means only IPv4 (A) records are shown and all IPv6 (AAAA) records are excluded.\n\nEven though dns.qry.type == 1 appears in both queries and responses, queries are already removed by dns.flags.response == 1.\n\n📌 Rule to Remember:\n✅ If dns.qry.type == 1 is in the filter, only IPv4 (A) records will appear, and IPv6 (AAAA) records will be automatically excluded.\n\n🚀 Final Summary: The Complete DNS Filter Logic\n\ndns.flags.response == 1 and dns.qry.name contains \"reebok.com\" and dns.qry.type == 1\n✅ dns.flags.response == 1 → Ensures that only responses (not queries) are displayed.\n✅ dns.qry.name contains \"reebok.com\" → Ensures that only responses related to reebok.com appear.\n✅ dns.qry.type == 1 → Ensures that only IPv4 (A) records appear, excluding IPv6 (AAAA).\n\n🚀 By combining these three conditions, this filter precisely captures the DNS resolution response for reebok.com, removing all unnecessary traffic.\n\n\n\n\n\n**Findings:**\n✅ Reebok.com was resolved to 23.227.38.65.\n✅ The DNS request was handled by a local resolver (dsldevice6.attlocal.net).\n✅ Resolution time: 0.079555000 seconds (likely cached).\n\n**🔹 Conclusion: The Full Network Flow (DNS ➝ TCP ➝ TLS ➝ HTTPS)**\n\n✅ DNS Query: reebok.com was resolved to 23.227.38.65\n✅ Connection Type: IPv4, TCP-based (not QUIC)\n✅ TCP Handshake: SYN, SYN-ACK, ACK confirmed\n✅ TLS Handshake: TLS 1.3, TLS_AES_128_GCM_SHA256 cipher suite, Perfect Forward Secrecy\n✅ Encryption Activation: TLS handshake completed, Change Cipher Spec and encrypted HTTPS traffic confirmed\n\n**🔹 Strategy Overview: Why This Approach Works**\n\n📌 Why Not Start With DNS?\n\nWe first verified that an actual connection was established before checking DNS.\n\nIf we had started with DNS, we would have captured all DNS responses (not just the relevant one).\n\nBy filtering only after confirming the IP used, we reduced noise and unnecessary steps.\n\n📌 Why Use These Filters Instead of Broad Queries?\n\nFiltering at each layer (DNS, TCP, TLS) ensures minimal irrelevant traffic.\n\nMore precise filtering leads to more efficient analysis and eliminates manual searching.\n\n📌 How This Improves Over Traditional Network Analysis\n\nTraditional Wireshark analysis often follows a broad, chronological approach.\n\nThis structured method narrows the scope at each step, ensuring only relevant packets are analyzed.\n\n\n**📌 Summary: A Repeatable, Optimized Approach**\n✅ Use filtering to analyze secure network traffic efficiently.\n\n✅ Avoid broad captures; target specific records to eliminate noise.\n\n✅ Follow the network flow in a logical sequence to confirm each stage.\n\n🚀 This structured approach provides a clear, repeatable process for analyzing web traffic efficiently in Wireshark.\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcompcode1%2Fwireshark-flow-execution","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcompcode1%2Fwireshark-flow-execution","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcompcode1%2Fwireshark-flow-execution/lists"}