An overview of TLS 1.3 and Q&A
The CloudFlare London office hosts weekly internal Tech Talks (with free lunch picked by the speaker). My recent one was an explanation of the latest version of TLS, 1.3, how it works and why it's faster and safer.
You can watch the complete talk below or just read my summarized transcript.
The Q&A session is open! Send us your questions about TLS 1.3 at [email protected] or leave them in the Disqus comments below and I'll answer them in an upcoming blog post.
Summarized transcript
To understand why TLS 1.3 is awesome, we need to take a step back and look at how TLS 1.2 works. In particular we will look at modern TLS 1.2, the kind that a recent browser would use when connecting to the CloudFlare edge.
The client starts by sending a message called the ClientHello that essentially says "hey, I want to speak TLS 1.2, with one of these cipher suites".
The server receives that and answers with a ServerHello that says "sure, let's speak TLS 1.2, and I pick this cipher suite".
Along with that the server sends its key share. The Continue reading
Worth Reading: Google as an advertising gatekeeper
The post Worth Reading: Google as an advertising gatekeeper appeared first on 'net work.
How to Be A Continuous Testing Hero
CT ensures that a new feature is tested at every stage from planning to design.
Common Criteria: Certified Products Galore!
If you track the WLAN security oriented certifications closely, you may have noticed that Ruckus was recently certified for Common Criteria.Junos MTU Handling on Access & Trunk Ports)
MTU is most important aspect for proper functionality of any application. In this blog post I will highlight MTU handling by Junos based devices for (802.3 un-tag and 802.1Q tag packets) .
Simple 802.3 packet header is shown above total packet size is 1514 bytes (14 bytes header + 1500 bytes max payload). Now we will see how Junos based devices handle MTU on access ports.
- LAB> show interfaces xe-1/0/32
Physical interface: xe-1/0/32, Enabled, Physical link is UpLink-level type: Ethernet, MTU: 1514, MRU: 0, Link-mode: Auto, Speed: Auto, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled, Flow control: Disabled, Auto-negotiation: Disabled,
———-output omitted for brevity——————–
Protocol eth-switch, MTU: 1514 - LAB > monitor traffic interface xe-1/0/32 no-resolve layer2-headers print-hex 02:09:00.266841 Out 00:31:46:52:dd:80 > 00:1e:0b:d3:1d:1a, ethertype 802.1Q (0x8100), length 1486: vlan 243, p 0, ethertype IPv4, truncated-ip – 32 bytes missing!
(tos 0x0, ttl 64, id 49385, offset 0, flags [DF], proto: ICMP (1), length: 1500)
192.168.243.1 > 192.168.243.52: ICMP echo reply, id 29316, seq 5, length 1480
- As we can see an access interface “xe-1/0/32″ showing MTU 1514 but when we monitor traffic on Continue reading
Saving Backup/Rescue Config on Juniper
A lot of times I find myself having to back a config up on a Juniper before I start work. Usually, I want a quick point I can restore to if I need to rollback. So enter rescue configurations to the, errr, rescue?
request system configuration rescue save
This saves the current saved system configuration as a rescue configuration you can easily rollback to with.
#rollback rescue
#commit
You can also save the current configuration to file using:
>file copy /config/juniper.conf.gz /var/tmp/temp_backup.cfg
/config/juniper.conf.gz is synonymous with the current running configuration.
Potentially, you could stash files in /var/tmp/ and restore them using the above. And restore using your backup with #load replace /var/tmp/temp_backup.cfg
View your stashed files using file list /var/tmp
