UPI Study › Courses › Ethics in Technology › Free lessons › Lesson 10.3 Free with a free account
Encryption Protocols and Secure Communication Standards
Ethics in Technology · Chapter 10: Defending the Network: Firewalls, VPNs, and Security PoliciesSection 10.3 · lesson 54 of 11614 min · free with a free account
Free preview
Create a free account to keep watching
It takes a minute and costs nothing. Your free account unlocks all of Chapter 1 and 3 more lessons of Ethics in Technology.
Lesson complete
Earn the 3 college credits for Ethics in Technology
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: Comparing Network Protection Approaches →← Authentication, Access Control, and Identity VerificationNext lesson: Comparing Network Protection Approaches →
In this lesson
Choose protection for the actual endpoints, path, and information.
- Connect transit threats with confidentiality, integrity, and authentication.
- Explain TLS, HTTPS, IPsec, SSH, and Wi-Fi protection.
- Compare email-message protection with transport protection.
- Assess protocol coverage and remaining metadata.
Free study notes
Get this lesson's notes by email
The key points and 4 practice questions with answers, in your inbox. One email, free.
One email. Unsubscribe in one click.
Transcript
Everything said in the video, section by section (1,658 words). Read along, or search it.
Chapter 10
Secure Communication
Secure communication protects information as it moves between devices. The main goals are confidentiality, integrity, and appropriate authentication. Different protocols protect different stretches of a path or different information objects. Wireless security covers the device-to-access-point hop. TLS protects an application connection, while HTTPS uses it for web communication. IPsec protects selected network-layer traffic between configured hosts or gateways. SSH supports protected remote administration and related transfers. S/MIME and OpenPGP can protect email contents beyond individual transport hops, including intermediate storage. Correct peer verification, configuration, endpoints, and key custody determine the actual assurance. Priya's café example separates protected content from metadata that observers may still learn. We finish by choosing suitable coverage for each need, rather than assuming one protocol protects everything everywhere.
Data in Transit
Protect Moving Information Against Reading, Alteration, and Impersonation
Data in transit is information moving across a network, rather than information stored on disk. That journey may cross equipment the user does not control. Eavesdropping threatens confidentiality by exposing content to unauthorized readers. Tampering threatens integrity by changing protected information. Impersonation threatens authentication by pretending to be a service or sender. A communication protocol supplies agreed rules for establishing relevant protection. Encryption still needs suitable peer verification and secure endpoints. Not every protocol automatically authenticates both parties. Ordinary web TLS generally authenticates the server, while the application handles user sign-in separately. The number of routers varies, and calling a network private does not establish every protection. Match protection to the actual communication. Familiarity and network location do not establish safety.
Where Protection Ends
Different Protocols Protect Different Stretches or Objects
The simplified route runs from the user device through an access point and network to a service. Wireless security covers only the device-to-access-point link. IPsec covers selected traffic between its configured hosts or gateways. TLS covers the actual programs or components terminating that connection. An authorized proxy or gateway may be a TLS endpoint before the final application. SSH protects communication between the client and its verified server. Message encryption protects an email object for intended key holders, even during intermediate storage. These boundaries are related but different. The layer labels are a teaching map, and TLS can also be integrated with transports such as QUIC. Combine protections when they address different exposure along the same journey. Always identify the real endpoints and key holders, rather than extending a protection beyond where it actually ends.
TLS and HTTPS
A Handshake Establishes Protected Communication and Relevant Peer Identity
TLS stands for Transport Layer Security and replaces obsolete SSL protocols. HTTPS protects HTTP exchanges using TLS. The client and server negotiate compatible secure options and establish cryptographic material. For ordinary web authentication, the client validates the certificate chain and intended hostname. Validity and configured policy checks matter alongside that identity relationship. A trusted certificate authority signs certificates under its validation policy. Domain validation supports control of the domain, rather than proving that its operator is honest. Negotiated keys protect exchanged content against unauthorized reading and alteration. The source handshake simplifies a process whose messages vary by version and authentication mode. User authentication usually occurs separately unless the connection is configured for suitable client evidence. Investigate certificate and hostname warnings through the approved process, instead of simply accepting away the intended assurance.
Versions and HTTPS Limits
Use Maintained Secure Configuration, and Separate Connection Assurance from Site Honesty
SSL versions two and three are obsolete and unsafe. TLS versions one point zero and one point one were formally deprecated in March twenty twenty-one. TLS one point two remains in use where required, with security dependent on maintained implementation and suitable configuration. TLS one point three was originally standardized in twenty eighteen and has received later specification maintenance. It removes older options and improves negotiation. HTTPS protects content between its actual endpoints, rather than guaranteeing safe storage or uncompromised devices. A dishonest look-alike site can have a valid certificate for its own hostname. Browser indicators vary, and Chrome replaced its top-level lock with site controls. Read the address and connection information rather than treating an icon as a trust badge. Ordinary DNS or handshake information can reveal domain names; encrypted DNS and Encrypted Client Hello can reduce that exposure. Addresses, timing, and sizes can still reveal useful metadata, so encryption does not mean complete anonymity.
IPsec
Protect Selected IP Traffic Between Configured Hosts or Gateways
IPsec protects selected traffic at the network layer. Authentication Header supplies integrity and data-origin authentication, without content encryption. Encapsulating Security Payload supplies configured confidentiality and integrity-related protection. The chosen security association determines its actual services. Internet Key Exchange establishes relevant keys, peer authentication, and security associations. Transport mode protects packet payload between hosts without encrypting the original IP header as part of that payload. Tunnel mode encapsulates an original packet within a new packet between tunnel endpoints. A site-to-site VPN can protect many application flows without each application implementing IPsec. Policy determines which traffic is protected, bypassed, or discarded. A gateway tunnel does not automatically protect traffic before entry or after exit. IKE commonly uses UDP five hundred, with four thousand five hundred for NAT traversal; ESP and AH are IP protocols.
SSH
Secure Remote Administration Depends on Verifying the Server and Protecting Client Keys
SSH provides secure remote access and related transfers for authorized users. Tatu Ylönen introduced it in nineteen ninety-five after a university-network security incident. It replaced plaintext legacy access such as Telnet. Uses include remote commands, supported SFTP or SCP transfer, tunneling, and authorized automation. The server's host key establishes server identity through the configured trust mechanism. That host key differs from the user's client authentication key. A fingerprint lets the user compare it with an independently trusted reference. A first-connection prompt alone does not establish that the host is genuine. An unexpected key change can reflect interception or a legitimate replacement, so investigate before accepting it. Protect private client keys and limit administrative permissions. Maintained SSH still depends on authorization, endpoint security, and network policy rather than granting safe unrestricted access from everywhere.
Wireless Security
Secure the Wireless Hop Without Assuming the Rest of the Journey Is Covered
Wi-Fi protection secures the wireless hop, where radio signals can be observed nearby. WEP has serious weaknesses and is unsuitable for modern protection. Original WPA and obsolete TKIP configurations should also be avoided. Maintained WPA two with AES remains an option when stronger supported modes are unavailable. The twenty seventeen KRACK findings exposed handshake weaknesses and reinforced the need for updates. WPA three Personal uses SAE to improve passive offline guessing resistance and provide forward secrecy when correctly implemented. Enterprise arrangements use suitable organizational authentication, often individual credentials or certificates. Enhanced Open uses opportunistic wireless encryption for supported open networks. That is a separate distinction, rather than a function guaranteed by every WPA three network. It encrypts the link without authenticating the access point or user. Actual negotiation, compatibility, updates, and key handling matter, and protection beyond the access point still needs other protocols.
Email Message Protection
Encrypting the Message Can Protect It Beyond Each Mail-Transport Connection
TLS between mail systems protects each negotiated transport hop. It does not by itself encrypt a message body while stored on those systems. S/MIME and OpenPGP offer message encryption and digital signatures as distinct operations. S/MIME commonly uses certificates and an issuer hierarchy, with suitable client and organizational management. OpenPGP keys can be verified directly, through trusted relationships, or other configured models. Its trust is not limited to one mandatory web of trust. Phil Zimmermann introduced PGP in nineteen ninety-one, and tools such as GnuPG support the broader ecosystem. Encryption limits reading to relevant private-key holders, while genuine end-to-end protection depends on their custody. A valid signature supports integrity and a signing-key relationship rather than proving every statement true. Routing addresses and timing remain relevant to delivery, and subjects often remain visible depending on protected headers. Key verification, lifecycle, recovery, and where decryption occurs determine the practical protection.
Priya in the Café
Assess Each Observer’s Position, and Keep Content Separate from Metadata
Priya connects in a café, browses her bank, accesses a company server, and sends encrypted email. Suitable WPA three link protection resists passive reading of unicast traffic over the air. The access point is an endpoint for wireless protection, rather than an ordinary outside observer of that link. Correct HTTPS protects bank pages, forms, and passwords between verified TLS endpoints. Destination information may remain available through network observations, depending on DNS and handshake privacy. Verified SSH protects commands and supported content while server address, timing, and size may remain visible. S/MIME protects encrypted message contents from intermediaries without the relevant private keys. Mail systems still need envelope information and can observe timing. Observer access, wireless configuration, isolation, proxies, and key custody change the detailed answer. The table is conceptual, rather than a claim that every nearby user sees identical information. No café password establishes the bank's honesty. Correct HTTPS protects bank content from the access point.
Selecting a Protocol
Match the Communication Need to Its Required Endpoints and Coverage
Choose a protocol by naming the communication need and required protection boundary. For web or application exchanges, use suitable TLS with intended-peer verification. HTTPS commonly uses port four hundred forty-three, through TCP or QUIC-based UDP as appropriate. For a configured network-to-network link, IPsec can protect selected flows. For remote administration and supported transfer, SSH uses verified host identity and scoped user access. Its common port is TCP twenty-two. For a wireless link, use a suitable maintained security mode supported by the devices. For email contents across intermediate storage, appropriate message encryption and signing add different assurance. Wireless security and message formats do not each have one dedicated application port. A port number alone proves neither the protocol nor the safety of its configuration. Verify negotiation, identities, endpoints, policy, keys, updates, and recovery, while testing the actual boundaries.
Review
Explain the Assurance, the Boundary, and What Still Needs Protection
Review the three transit goals as confidentiality, integrity, and appropriate authentication. Mutual identity is not automatically provided in every ordinary connection. A connection indicator can accompany a validated hostname without proving that its operator is honest. IPsec protects selected IP flows between configured endpoints, while TLS protects its application connection. Suitable WPA three improves wireless protection, with open-network opportunistic encryption as a separate distinction. Actual mode and configuration remain important. Encrypted email can protect stored content beyond mail TLS, subject to private-key custody and where decryption occurs. Apply the café pattern by identifying sender, recipient, intermediate systems, encryption endpoints, and key holders. Explain which content and metadata an observer can still see. Protected transit complements secure storage, trustworthy endpoints, legitimate authorization, and careful judgment. Verify addresses and identities, respect warnings, and maintain the implemented protections rather than relying only on familiar names.
About Ethics in Technology at UPI Study
Ethics in Technology (Computer Science 195) is a self-paced online course of 116 video lessons in 15 chapters, from cybersecurity basics, privacy and surveillance to big data, hacking, malware, network defense, intellectual property, cybercrime, encryption, emerging technology and digital citizenship. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus All Computer Science courses
Compare: Cybersecurity vs Ethics in Technology · Which ethics course?
Why take it here
Why students take Ethics in Technology with UPI Study
Where the credit goes
Universities that work with NCCRS
Ethics in Technology carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About Encryption Protocols and Secure Communication Standards
What is the difference between TLS and HTTPS?
Does HTTPS mean a website is safe?
What is the difference between IPsec transport mode and tunnel mode?
Which Wi-Fi security protocol should you use?
About the Ethics in Technology course
How many college credits is Ethics in Technology?
How much does Ethics in Technology cost and what is included?
Which universities accept UPI Study credits?
How long does Ethics in Technology take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in Ethics in Technology.
116 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →