HTTP, HTTPS, TLS and Essential Network Services

Learning objective

Identify how six essential application services use ports, transports, messages, security, and packet evidence to deliver useful network functions.

HTTP, HTTPS, and web services

HTTP/1.1 message format

Swipe sideways to see all fields

HTTP request message format

Request line · GET /guide HTTP/1.1

Header fields · Host: packetsecrets.com

Blank line · ends the header section

Optional request body

Swipe sideways to see all fields

HTTP response message format

Status line · HTTP/1.1 200 OK

Header fields · Content-Type: text/html

Blank line · ends the header section

Optional response body

HTTP is a request-and-response application protocol. A client opens a TCP connection to a listening web service, sends a request such as GET /guide HTTP/1.1 with a Host header, and receives a status line, headers, and an optional body. 80 is the conventional HTTP port, 443 is HTTPS, and 8080 is a common explicitly selected alternate HTTP port.

The source port identifies this client connection while the destination port identifies the server listener. Routers forward the IP packets; the server TCP stack delivers the byte stream to the matching socket. A proxy or load balancer may terminate the connection and create another one toward the application.

HTTPS means HTTP carried through modern TLS protection. The old name SSL remains common in product labels, but SSL protocols are obsolete; TLS provides the current confidentiality, integrity, and server-authentication layer. Detailed TLS negotiation belongs in the dedicated SSL/TLS lesson.

If the TCP handshake fails, first check addressing, routing, filtering, and the listener. If TCP succeeds but HTTP returns 404, 403, or 500, the application did respond—investigate the request target, authorization, or server logic rather than calling it a port failure.

Quick check: Port 443 alone suggests an HTTPS listener, but packet evidence and configuration establish what actually runs there.

SSH and Telnet remote access

Remote terminal services let an administrator operate another system. SSH uses TCP 22 and begins with protocol identification before negotiating protected authentication and session channels. Telnet uses TCP 23 and negotiates terminal behavior, but it does not encrypt credentials or commands.

The administrator's client selects an ephemeral source port and connects to the managed device. Each router forwards the packets without interpreting the command session. The destination host maps TCP 22 or 23 to the listening process and returns traffic to the client's source port.

Prefer SSH and validate the server host key; a changed key may indicate a rebuilt device or an interception risk. Telnet should be recognized as a legacy clear-text protocol, not selected for management across an untrusted network.

Connection refused usually means the host is reachable but no permitted service is listening. A timeout can indicate routing, filtering, address, or return-path trouble. An SSH authentication rejection occurs later and should be investigated as an identity, method, or policy problem.

Quick check: Seeing TCP 22 proves the selected port, not that host-key verification or user authentication succeeded.

SMTP, IMAP, and POP3 email services

Email uses different protocols for different jobs. SMTP relays mail between servers on TCP 25 and commonly accepts authenticated client submission on TCP 587; TCP 465 starts protected SMTP submission with implicit TLS. SMTP commands and replies operate on an envelope before the message content is transferred.

Mailbox retrieval is separate from delivery. IMAP synchronizes server-held mailboxes on TCP 143, or 993 with implicit TLS. POP3 offers a simpler download-oriented model on TCP 110, or 995 with implicit TLS. A sender can therefore submit successfully even when the recipient later has an IMAP problem.

The client connects to a submission server, which may queue the message and create new SMTP connections to other mail servers. The recipient reads the stored message through an independent IMAP or POP3 connection. Each leg has its own addresses, ports, security, and result codes.

Protect credentials and content with TLS and use authenticated submission rather than treating port 25 as a general user-login service. A 5xx SMTP reply is a permanent rejection; a 4xx reply normally asks the sender to retry. Retrieval login failure does not prove SMTP delivery failed.

Quick check: SMTP sends or relays messages; IMAP and POP3 retrieve them. They are complementary, not interchangeable.

FTP, FTPS, and SFTP file transfer

Classic FTP separates commands from file data. The persistent control connection normally reaches TCP 21. In active mode the server traditionally initiates a data connection from TCP 20; in passive mode the server advertises a negotiated high port and the client initiates the data connection.

This two-connection design matters at firewalls and NAT devices: successful login proves only that the control path works. A directory listing or transfer can still fail when the negotiated data path is blocked.

FTPS is FTP protected with TLS and retains FTP's separate-channel behavior; TCP 990 is associated with implicit FTPS control. SFTP is not FTP with another security option: it is an SSH subsystem, normally over TCP 22, with a different message and channel design.

Avoid unprotected FTP when credentials or data require confidentiality. When troubleshooting, determine the protocol first, then identify control versus data connections and active versus passive direction. Do not open TCP 20 for an SFTP problem.

Quick check: FTPS uses FTP semantics with TLS; SFTP uses SSH semantics. Similar names do not mean wire compatibility.

NTP time synchronization

NTP commonly uses UDP 123 to compare clocks. A client exchange records four timestamps: T1 client transmit, T2 server receive, T3 server transmit, and T4 client receive. From them, the client estimates round-trip delay and clock offset instead of simply copying the server's visible time.

The request travels from a client source port to UDP 123; the response returns with the server and client ports reversed. NTP also evaluates clock hierarchy and quality information so an apparently reachable source is not automatically a trustworthy synchronization source.

Accurate time supports logs, certificates, authentication, distributed systems, and incident timelines. Restrict unnecessary NTP service exposure and use approved, trustworthy sources. A reply with an unacceptable stratum or leap state may be correctly transported but unsuitable for synchronization.

If no reply arrives, check UDP filtering and return routing. If replies arrive but the clock stays unsynchronized, inspect offset, delay, source selection, stratum, leap indicator, and local service policy.

Quick check: UDP 123 reachability is necessary, but the four timestamps and source-quality rules decide whether time can be corrected safely.

SNMP monitoring and notifications

SNMP separates a manager from agents on managed devices. A manager normally sends operations such as GetRequest to an agent on UDP 161. An agent sends event notifications to a manager's listener on UDP 162. A Trap is unacknowledged; an Inform expects a response.

An OID identifies a managed object in a hierarchical namespace, while a MIB supplies names, types, and meaning for those objects. The packet carries an operation plus identifiers and values; the MIB is not shipped inside every request. Polling and notifications therefore travel in opposite operational directions even though both support monitoring.

Prefer SNMPv3 security features where supported and scope access to the minimum objects and managers required. Community strings in older versions are not equivalent to strong user authentication and privacy.

A timeout may mean filtering, wrong address, missing agent, or mismatched security parameters. An error response proves the agent replied but could not perform the requested operation. A graph gap may also be a manager collection or OID-selection problem rather than device failure.

Quick check: UDP 161 is normally the agent's request listener; UDP 162 is normally the manager's notification listener.

Trace a web request and response

Follow HTTP on 80, HTTPS on 443, and an alternate listener on 8080. At each step, connect the selected service port to the message fields and capture evidence.

HTTP and HTTPS service journey

browserbrowser to web-server✉web-serverWeb

PreviousPlayNextRestartPlayback speed 0.5×1×1.5×2×

Step 1 of 3: HTTP request

The browser sends a clear-text HTTP request after transport setup.

Active transport: TCP 51000 → 80

Capture evidence: tcp.dstport == 80 && http.request

HTTP request

Field	Value	Meaning
Method	GET	Requests a representation.
Host	www.example.test	Selects the virtual host.

Troubleshoot web-service evidence

Separate transport failure from an application status response, then choose the next check supported by the evidence.

Web troubleshooting

Case The browser reports too many redirectsA proxy returns 504 Gateway Timeout

Evidence: Repeated 301 and 302 responses point back to earlier URLs

Choose the best diagnosis

Check the redirect targetReplace the network cable

How confident are you?

UnderconfidentConfident

Check diagnosis

Knowledge check: A server returns HTTP 404. What has already succeeded?

At least enough transport and HTTP processing to return a responseThe requested resource was foundTLS certificate validation must have failed

Check answer

Trace SSH and Telnet sessions

Compare protected SSH on TCP 22 with clear-text Telnet on TCP 23, including the server identity and terminal negotiation evidence each exposes.

SSH and Telnet service journey

administratoradministrator to network-device✉network-deviceRemote access

PreviousPlayNextRestartPlayback speed 0.5×1×1.5×2×

Step 1 of 2: Protected SSH session

SSH protects authentication and commands over the remote-access session.

Active transport: TCP 52000 → 22

Capture evidence: tcp.dstport == 22

SSH identification

Field	Value	Meaning
Protocol	SSH-2.0	Negotiates the SSH protocol generation.
Host identity	host key	Lets the client validate the server identity.

Troubleshoot remote access

Use connection results to distinguish routing or filtering, a closed listener, host-key concerns, and user-authentication policy.

Remote access troubleshooting

Case SSH warns that the host key changedCredentials appear readable in a capture

Evidence: The presented server identity differs from the saved key

Choose the best diagnosis

Verify the new host key out of bandIgnore the warning permanently

How confident are you?

UnderconfidentConfident

Check diagnosis

Knowledge check: Why is SSH preferred to Telnet for administration?

SSH protects authentication and commandsSSH does not use TCPTelnet cannot carry terminal text

Check answer

Trace submission, relay, and mailbox retrieval

Follow SMTP submission and relay separately from IMAP and POP3 retrieval. Watch the role, port, command, and reply change across the complete mail path.

Email submission, relay, and retrieval journey

mail-servermail-server to mail-server✉mail-serverEmail

PreviousPlayNextRestartPlayback speed 0.5×1×1.5×2×

Step 1 of 7: SMTP server relay

Mail servers commonly exchange SMTP traffic on port 25.

Active transport: TCP 53000 → 25

Capture evidence: tcp.dstport == 25 && smtp

SMTP relay

Field	Value	Meaning
Command	MAIL FROM	Begins the message envelope.
Reply	250	Reports successful processing.

Troubleshoot email services

Locate the failing leg before changing settings: submission, server relay, message acceptance, mailbox storage, or client retrieval.

Email troubleshooting

Case SMTP relay rejected the recipientMail sends successfully but the inbox will not synchronize

Evidence: The server replied 550 5.1.1 during RCPT TO

Choose the best diagnosis

Verify the recipient addressRestart the IMAP mailbox

How confident are you?

UnderconfidentConfident

Check diagnosis

Knowledge check: Which protocol normally synchronizes a server-held mailbox?

IMAPSMTP relayNTP

Check answer

Trace FTP, FTPS, and SFTP

Observe FTP control and active/passive data connections, then compare FTPS protection with the different SSH-based SFTP design.

FTP, FTPS, and SFTP journey

ftp-clientftp-client to ftp-server✉ftp-serverFile transfer

PreviousPlayNextRestartPlayback speed 0.5×1×1.5×2×

Step 1 of 5: FTP control channel

FTP commands use the control channel on port 21.

Active transport: TCP 54000 → 21

Capture evidence: tcp.dstport == 21 && ftp

FTP command

Field	Value	Meaning
Command	USER learner	Travels on the persistent control channel.
Channel	control	Keeps commands separate from file data.

Troubleshoot file transfers

Identify the actual protocol and determine whether authentication, the FTP control channel, or a separately negotiated data channel failed.

File transfer troubleshooting

Case FTP login works but active transfers failAn FTP client cannot connect to an SFTP-only service

Evidence: The server-initiated data connection is blocked

Choose the best diagnosis

Use passive mode or permit the data flowChange the SSH host key

How confident are you?

UnderconfidentConfident

Check diagnosis

Knowledge check: What distinguishes SFTP from FTPS?

SFTP is an SSH subsystem; FTPS applies TLS to FTPSFTP always uses UDPFTPS has no control channel

Check answer

Trace an NTP exchange

Inspect T1 through T4 and connect each timestamp to the delay and offset evidence used for clock correction.

NTP time synchronization journey

ntp-clientntp-client to ntp-server✉ntp-serverTime

PreviousPlayNextRestartPlayback speed 0.5×1×1.5×2×

Step 1 of 1: Calculate delay and offset

The four timestamps let the client estimate network delay and clock offset.

Active transport: UDP 55000 → 123

Capture evidence: udp.dstport == 123 || udp.srcport == 123

NTP exchange

Field	Value	Meaning
T1 origin timestamp	client send	Records when the client transmitted the request.
T2 receive timestamp	server receive	Records when the server received it.
T3 transmit timestamp	server send	Records when the server transmitted the response.
T4 destination timestamp	client receive	Records when the client received the response.

Conclusion

NTP uses measured timestamps and a clock hierarchy to improve system time rather than simply copying one value.

Troubleshoot time synchronization

Distinguish UDP reachability from source-quality, excessive-offset, selection, and local clock-service problems.

Time troubleshooting

Case The NTP peer remains unreachableThe clock repeatedly steps by a large amount

Evidence: No UDP 123 response returns and reach stays zero

Choose the best diagnosis

Check UDP 123 routing and filteringClear the HTTP cache

How confident are you?

UnderconfidentConfident

Check diagnosis

Knowledge check: What do NTP's four timestamps help estimate?

Round-trip delay and clock offsetThe server's TCP windowA DNS record lifetime

Check answer

Trace SNMP polling and notification

Compare a manager poll to UDP 161 with Trap and Inform notifications toward UDP 162, while reading the operation and OID fields.

SNMP polling and notification journey

snmp-managersnmp-manager to snmp-agent✉snmp-agentMonitoring

PreviousPlayNextRestartPlayback speed 0.5×1×1.5×2×

Step 1 of 3: Manager polls an agent

Managers normally send polls to an agent on UDP 161.

Active transport: UDP 56000 → 161

Capture evidence: udp.dstport == 161 && snmp

SNMP GetRequest

Field	Value	Meaning
Operation	GetRequest	Requests one or more managed objects.
OID	1.3.6.1.2.1.1.3.0	Identifies a managed value in the MIB tree.

Troubleshoot monitoring evidence

Separate missing transport, mismatched security parameters, an unsupported OID, an agent error, and manager-side collection trouble.

Monitoring troubleshooting

Case SNMP polling times out on a legacy devicePolling works but alerts never arrive

Evidence: UDP 161 reaches the agent but the community does not match

Choose the best diagnosis

Verify credentials and prefer SNMPv3Open FTP passive ports

How confident are you?

UnderconfidentConfident

Check diagnosis

Knowledge check: Where are SNMP notifications normally sent?

To the manager's UDP 162 listenerTo the agent's TCP 161 listenerTo the DNS resolver on UDP 53

Check answer

Essential services checkpoint

Match every symptom to a specific connection leg, transport, destination port, message field, and response. A familiar port is a strong clue, but the observed exchange is the evidence.

Web-service Wireshark analysis

Correlate the TCP conversation with the HTTP request line, Host, response status, framing headers, and proxy addresses. Decide whether a cache served the representation and whether the capture point is before or after a reverse proxy. For HTTPS, use connection metadata only as introductory evidence; encrypted HTTP and detailed TLS mechanics are treated in their dedicated lessons.

HTTP capture

Display filter: http || tcp.port == 443

192.0.2.10 exchanges HTTP traffic with 198.51.100.80.

No.	Time	Source	Destination	Protocol	Length	Info
1	0.000000	192.0.2.10	198.51.100.80	HTTP	74	GET / HTTP/1.1
2	0.024100	198.51.100.80	192.0.2.10	HTTP	86	Response: GET / HTTP/1.1

Which evidence best identifies this HTTP conversation?

request method, status, and TCP service portThe Ethernet vendor name alone

Check capture evidence

Web-service RFC validation

Apply HTTP semantics to framing and intermediary behavior. Distinguish a valid application response from a transport success, and explain how ambiguous message length can affect a reused connection.

RFC-level validation

A response sends both an invalid framing length and a conflicting message boundary. Is it valid?

ValidInvalid

Check RFC decisionRFC 9110

Remote-access Wireshark analysis

Identify the SSH protocol banner, negotiated direction, and host-key evidence without claiming that TCP 22 alone authenticates the server. Contrast this with readable Telnet negotiation and payload, and determine whether failure occurs before identification, during negotiation, or at user authentication.

SSH capture

Display filter: ssh || tcp.port == 23

192.0.2.10 exchanges SSH traffic with 198.51.100.22.

No.	Time	Source	Destination	Protocol	Length	Info
1	0.000000	192.0.2.10	198.51.100.22	SSH	74	Protocol exchange
2	0.024100	198.51.100.22	192.0.2.10	SSH	86	Response: Protocol exchange

Which evidence best identifies this SSH conversation?

SSH identification or clear-text Telnet dataThe Ethernet vendor name alone

Check capture evidence

Remote-access RFC validation

Evaluate SSH transport expectations around identification and server authentication. Explain why blindly accepting a changed host key defeats a critical identity check even when encryption is present.

RFC-level validation

An SSH transport skips server host-key proof. Is it valid?

ValidInvalid

Check RFC decisionRFC 4253

Email-service Wireshark analysis

Reconstruct SMTP envelope commands and replies, then keep that state separate from message content and later IMAP or POP3 retrieval. Identify whether the trace shows client submission, server relay, mailbox selection, synchronization, or download, and note where protection begins.

SMTP capture

Display filter: smtp || imap || pop

192.0.2.25 exchanges SMTP traffic with 198.51.100.25.

No.	Time	Source	Destination	Protocol	Length	Info
1	0.000000	192.0.2.25	198.51.100.25	SMTP	74	MAIL FROM
2	0.024100	198.51.100.25	192.0.2.25	SMTP	86	Response: MAIL FROM

Which evidence best identifies this SMTP conversation?

mail command, reply code, and service portThe Ethernet vendor name alone

Check capture evidence

Email-service RFC validation

Classify reply codes by stage and persistence. Determine whether a sender should retry, correct the envelope, or investigate a later mailbox-access problem rather than treating every mail symptom as one SMTP failure.

RFC-level validation

An SMTP server accepts DATA before a valid recipient. Is it valid?

ValidInvalid

Check RFC decisionRFC 5321

File-transfer Wireshark analysis

Pair the FTP control dialogue with its active or passive data connection. Use direction, the PORT or PASV exchange, and negotiated endpoints to locate a NAT or firewall failure. Confirm whether the trace is FTP/FTPS or the distinct SFTP subsystem before interpreting ports.

FTP capture

Display filter: ftp || ftp-data || ssh

192.0.2.21 exchanges FTP traffic with 198.51.100.21.

No.	Time	Source	Destination	Protocol	Length	Info
1	0.000000	192.0.2.21	198.51.100.21	FTP	74	PASV
2	0.024100	198.51.100.21	192.0.2.21	FTP	86	Response: PASV

Which evidence best identifies this FTP conversation?

control and negotiated data conversationsThe Ethernet vendor name alone

Check capture evidence

File-transfer RFC validation

Validate the relationship between control state and transfer state. Explain why a successful login cannot prove that a separately created data connection is reachable, especially through address translation.

RFC-level validation

An FTP server sends file data over the control connection. Is it valid?

ValidInvalid

Check RFC decisionRFC 959

NTP Wireshark analysis

Read origin, receive, transmit, and destination timestamps as one exchange. Calculate what the trace can support about delay and offset, then inspect stratum, leap state, and reference information before declaring the source suitable.

NTP capture

Display filter: udp.port == 123

192.0.2.10 exchanges NTP traffic with 198.51.100.123.

No.	Time	Source	Destination	Protocol	Length	Info
1	0.000000	192.0.2.10	198.51.100.123	NTP	74	Client request
2	0.024100	198.51.100.123	192.0.2.10	NTP	86	Response: Client request

Which evidence best identifies this NTP conversation?

UDP port 123 and four timestampsThe Ethernet vendor name alone

Check capture evidence

NTP RFC validation

Apply clock-selection reasoning rather than choosing the first UDP 123 reply. Discuss asymmetric delay, implausible offset, unsynchronized sources, and why accurate local time is operationally more than a cosmetic setting.

RFC-level validation

An NTP reply omits usable originate and receive timestamps. Is it valid?

ValidInvalid

Check RFC decisionRFC 5905

SNMP Wireshark analysis

Match request IDs, operations, error fields, OIDs, and values across polling and notifications. Distinguish a Trap from an acknowledged Inform, and determine whether a missing graph point originates at the agent, network, security model, OID selection, or manager.

SNMP capture

Display filter: snmp || udp.port == 162

192.0.2.161 exchanges SNMP traffic with 198.51.100.162.

No.	Time	Source	Destination	Protocol	Length	Info
1	0.000000	192.0.2.161	198.51.100.162	SNMP	74	GetRequest
2	0.024100	198.51.100.162	192.0.2.161	SNMP	86	Response: GetRequest

Which evidence best identifies this SNMP conversation?

operation, request ID, OID, and error statusThe Ethernet vendor name alone

Check capture evidence

SNMP RFC validation

Validate operation direction and response rules, then discuss SNMPv3 identity, integrity, privacy, engine context, and replay protection at an operational level. Use the MIB to interpret an OID without claiming the MIB travelled in the packet.

RFC-level validation

An SNMP response changes the request-id from its request. Is it valid?

ValidInvalid

Check RFC decisionRFC 3416